Skip to content

Fix: separator isn't created + update installer for VS2026 - #19

Open
parties wants to merge 5 commits into
DrummerSi:masterfrom
parties:debug/taskbar-separator-not-working
Open

Fix: separator isn't created + update installer for VS2026#19
parties wants to merge 5 commits into
DrummerSi:masterfrom
parties:debug/taskbar-separator-not-working

Conversation

@parties

@parties parties commented Jul 27, 2026

Copy link
Copy Markdown

Dev Notes

tl;dr - I fixed most of the issues, I think. It's working on the latest build of Windows 11 on my local, tested a Release candidate locally, looks good to me.

I went ahead and fixed both main issues: the app didn't work when attempting to create separators AND the installer was out of date (latest Visual Studio supported version was 2015). I went ahead and updated the project and the installer to use Visual Studio 2026, replaced the older installer with Wix, and fixed the bug that prevented the separators from working.

If you want me to split this into separate PRs I can.

Summary

Clicking Create Separator appeared to do nothing — no separator showed up on the taskbar. The files and shortcut were being created correctly, but the separator window never launched. This PR fixes the root cause and cleans up a related corrupted character.

Root cause

The ShellExecute P/Invoke in MainForm was declared without a CharSet:

[DllImport("shell32.dll")]   // defaults to CharSet.Ansi → binds to ShellExecuteA

The generated shortcut filenames use a non-ANSI character (a ). Under the default ANSI marshalling, that character can't be represented in the system code page and degrades to ?, so ShellExecuteA was handed a path that doesn't exist on disk. It returned HINSTANCE = 2 (ERROR_FILE_NOT_FOUND) and launched nothing — with no exception and no error dialog, so the failure was completely silent.

This has been present since the first commit; it was not introduced by the recent .NET 10 retarget.

Changes

  1. ShellExecute marshals as Unicode — declaring CharSet = CharSet.Unicode binds to ShellExecuteW, which receives the shortcut path intact. ShellExecute now returns 42 (success) and the separator window launches.
  2. Restored the corrupted shortcut label character — the label char in GetNewLinkName had become U+FFFD (the Unicode replacement character) via an encoding round-trip. Restored it to the intended (U+25CF BLACK CIRCLE) and wrote it as a \u25CF escape so the source stays ASCII-safe and can't re-corrupt.

Testing

  • Instrumented the click handler and confirmed ShellExecute returned 2 (file-not-found) before the fix and 42 (success) after.
  • Drove the real Create Separator button via UI Automation against a clean state: 3/3 failed before, 3/3 launched (with a visible taskbar window) after.
  • Verified the shortcut is now named ●.lnk (U+25CF) instead of the replacement character.

Building

You will have to accept the license terms when building, which you can easily do on the command line with this:

dotnet build TaskSplitter11.sln -c Release -p:AcceptEula=true

If you need to update Github Actions, I'm pretty sure this is all you need:

- run: dotnet build TaskSplitter11.sln -c Release -p:AcceptEula=true

Related Issues

Pretty sure it resolves all these:

parties and others added 5 commits July 24, 2026 09:54
Replace the legacy Visual Studio setup project (Installer/Installer.vdproj)
with a WiX Toolset v7 MSI in Installer-Wix/.

- Reuse the old UpgradeCode so the WiX MSI upgrades existing installs
- Harvest the app build output via <Files> (pdbs excluded); install to
  Program Files\SiCo\Task Separator 11
- Desktop + Start Menu shortcuts (per-user, ICE57-clean)
- Require the .NET 6 Desktop Runtime via a netfx launch condition
- Remove the old vdproj; add Installer-Wix to the solution

Build with Visual Studio / MSBuild.exe (the app's COM reference is not
supported by "dotnet build").

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Retarget TaskSplitter11 and Splitter from EOL net6.0-windows to net10.0-windows (LTS)
- Remove the unused IWshRuntimeLibrary COM reference (shortcuts use WindowsShortcutFactory);
  the whole solution, including the WiX MSI, now builds with plain "dotnet build"
- Update the installer's .NET Desktop Runtime launch condition from 6.0 to 10.0

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… Unicode

The "Create Separator" button silently did nothing: files and the shortcut
were created correctly, but no separator window ever appeared.

Root cause: the ShellExecute P/Invoke had no CharSet, so it defaulted to
CharSet.Ansi and bound to ShellExecuteA. The generated .lnk filenames use a
non-ANSI character, which cannot be represented in the ANSI code page and
degrades to '?'. ShellExecuteA was therefore handed a non-existent path and
returned HINSTANCE=2 (ERROR_FILE_NOT_FOUND), launching nothing -- with no
exception or error dialog.

Declaring CharSet=CharSet.Unicode binds to ShellExecuteW, which receives the
filename intact. Verified end-to-end: the separator window now launches on
every "Create Separator" click.
The shortcut-name character in GetNewLinkName was U+FFFD (the Unicode
replacement character) -- mojibake left over from an encoding round-trip. The
upstream original used '●' (U+25CF BLACK CIRCLE), an unobtrusive dot used as
the separator shortcut's label.

Restore the intended character but write it as a ● escape so the source
stays ASCII-safe and cannot be corrupted again by an editor saving with the
wrong encoding.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant