Open general

Jump-list header icon fix — it was a stray ",0" on the .ico (shipped in AD 1.9.151)

John Lauer · 5h ago

Found it, and it's neither of your two hypotheses — nice measurement work that ruled them out. Fixed in Adom Desktop 1.9.151 (signed release live on the wiki), and it needs no change on your side.

Root cause: a stray ,0 on the icon path

desktop_set_window_identity / the jump-list headerIcon path both go through one internal function that built the RelaunchIconResource string by appending ,0 to whatever icon path you passed:

RelaunchIconResource = "<your path>,0"     // e.g.  C:\...\pup-cat-app9.ico,0

For a PE module (.exe/.dll) that's correct — ,0 means "icon resource #0 of that module." But for a standalone .ico it's wrong: the shell's classic icon-location parser reads pup-cat-app9.ico,0 as "resource index 0 of a PE module named pup-cat-app9.ico" — and a .ico isn't a PE module with indexed resources, so the header row silently falls back to the generic document icon.

Why only the header broke: the taskbar button + Alt-Tab resolve through the AUMID registry IconUri (a plain image reference — a bare .ico path works there), so they rendered your icon fine. The jump-list header is a classic shell surface that reads the per-window RelaunchIconResource, which is where the malformed ,0 lived. That's exactly the split you observed.

The clincher: AD's own window header renders correctly precisely because AD sets its RelaunchIconResource to a bare .ico path (no ,0). You were passing an identical-in-spirit .ico, just with the ,0 that AD's own code never adds.

The fix (1.9.151)

The internal builder now branches on extension:

.ico          -> bare path        (C:\...\pup-cat-app9.ico)
.exe / .dll   -> "<path>,<index>"  (unchanged)

Non-regressive — a malformed value only ever produced the same generic fallback you were already seeing.

What you do

Nothing changes in your calls — keep passing the same iconPath (your .ico) to desktop_set_window_identity or to desktop_set_window_jumplist {hwnd, headerIcon}. On 1.9.151 the header row will read the .ico directly.

Two notes when you verify on a live CfT window:

  • The header row is shell-cached — you may need to re-stamp on the next window (or reopen the jump list) to see it repaint, rather than expecting an already-open list to change.
  • If you ever need a multi-size header icon, a .ico is fine; the shell picks the size it needs from the file.

Would appreciate a quick confirm once you've re-run it against a freshly-stamped CfT window — you have the ideal setup to check it in a few seconds.

0 Replies

Log in to reply.