Set app icons via Manifest vs Programmatically

[petr-larin]

I can set app icons (eg title bar, task bar) via Manifest for packaged apps, but haven't figured out if this is possible for unpackaged, or programmaticaly is the only way here? Thank you!

[DarranRowe]

For icons that appear in start or for pinned icons, the displayed icon is always obtained from the shortcut.
For runtime icons, things can be a little tricky. But this is always the case for desktop applications. In the simplest case, the icon set for the window is what is used. This is always set programmatically, from the Windows API, this will either be set in the window class or it will be set using the WM_SETICON message sent to the window. The Windows App SDK does provide a nicer wrapper around this. Microsoft.UI.Windowing.AppWindow has the SetIcon member, so you can use that to set the window icon instead.

[petr-larin]

Thank you and that's right, I have used both WM_SETICON and the AppWindow wrapper for the unpackaged app. However, for the same app if I flip it to packaged, I no longer need them. The PackageManifest will do the job. I have removed the SetIcon wrapper call from the packaged version but am still getting the runtime icons all right. So was just curious if the same is possible for the unpackaged?

[DarranRowe]

Well, first of all, if you don't need WM_SETICON or the wrapper in a packaged application then there is something else doing that work.

Using the default WinUI 3 template, you can see that the titlebar icon is the Windows default icon. This was done with both a C++ and C# version. I even went as far as packaging up a Windows API application, making sure that the icon and small icon values in the window class were null, and it still used the default icon.

Secondly, for the taskbar, the links that Windows creates for the packaged application sets a Application User Model ID. This has been available since Windows 7, but to use it properly, you need to set this programmatically. Windows can get away with with packaged applications since it controls the shortcuts, but for an unpackaged application, there is always the risk of you running it directly through the executable.

[petr-larin]

Thank you. So it boils down to that we cannot use manifests for setting icons in unpackaged apps, rather we need to do that programmatically?

[DarranRowe]

That is correct.

[petr-larin]

Thank you! This answers my question.

I have another one, closely related: for my WinUI3 app, I want an icon to appear in the task bar, but disappear from the window title bar. This screen shot shows the desired behaviour:

This is a screen shot of a packaged app where I defined my icons via a manifest, and then I call this function to remove the icon just from the window title bar:

void HideTitleBarIcon(HWND win32_hwnd)
{
    auto ext_style = GetWindowLongPtrW(win32_hwnd, GWL_EXSTYLE) | WS_EX_DLGMODALFRAME;
    SetWindowLongPtrW(win32_hwnd, GWL_EXSTYLE, ext_style);
}

So, for packaged apps this works.

However, for unpackaged apps this trick only works for the default app icon (when I haven't set the custom icon via SetIcon). Once I have set my custom icon programmatically, this trick with EX window styles no longer works. This is a screen shot from the same app but unpackaged variant:

To reiterate the code is identical for both screen shots (both call HideTitleBarIcon) and the only difference is packaged/unpackaged.

This hints at that even programmatically, icons are handled differently in packaged vs unpackaged.

[DarranRowe]

If that is the case, then it is a huge difference.
When no icon has been set, the changing of the ex style can be done early on. For a Windows API application, this can happen as early as the WM_NCCREATE message. For WinUI 3, this can happen in the Window's constructor. The key thing here is that they happen before the window is visible. When you do anything else, it tends to force communication with the window through messages, and these tend to get posted and queued up after the other window creation messages, including making the window visible.
Once the default frame and titlebar has been drawn, it is a pain to get some things to change. In the case of the icon, the easiest method is to hide and show the window. I may have missed something, but just changing the frame style to WS_OVERLAPPED | WS_VISIBLE and then restoring the original style doesn't help, once it is restored to the original style the icon will be back.
But the important thing to point out, in a packaged application, if you have to change the icon in the titlebar after the window becomes visible, you have the exact same issues as an unpackaged application.

[petr-larin]

I think that we should draw the line not between packaged vs unpackaged, but between setting the icon programmatically vs manifest:

• If I set up the title bar icon via a manifest (not using SetIcon/WM_SETICON) then I can switch the icon on/off via changing the window class at any time after the window has become visible.

• If I set the title bar icon via SetIcon/WM_SETICON then it cannot be switched off via the window class trick.

The unpackaged/packaged dichotomy only comes into play because I cannot use manifest for unpackaged. But the root cause is Manifest vs Programmatically.

[DarranRowe]

Fine, let us draw the line between WinUI 3 and the raw Windows API too. Since this has devolved into trying to show if applying the WS_EX_DLGMODALFRAME has any effect on the title bar icon.

This youtube link has a capture of my attempts to set that style on Windows 11 in a Windows API desktop application. There was never any setting of the icon, the class never had an icon set which is shown. The left click handler sets the ex style, and the icon stays in the title bar.

So to put it simply, there are unknowns here. This difference could be explained by implementation defined behaviour, which then would warn you against using this trick because the behaviour is not consistent between versions. This also wouldn't be too surprising because there were changes to the frame along the way, 21H2 added the ability to use the host backdrop, immersive dark mode and set various attributes of the frame. 22H2 added the ability to change the frame's backdrop material.

Just to rule out some possible problems, the style for the WinUI 3 window had WS_OVERLAPPEDWINDOW, WS_CLIPSIBLINGS and WS_EX_WINDOWEDGE set. WS_CLIPSIBLINGS and WS_EX_WINDOWEDGE are automatically set, so they are also present on the Windows API application. I used GetClassLongPtr to get the icon and small icons set in the class, and they both return null. I even tried querying the icon using WM_GETICON, and that returned null. So the icon situation is exactly the same as the Windows API desktop application.

[petr-larin]

Thank you! I was able to reproduce the behavior which you're showing in your video. However, adding after line 162:

    ShowWindow(get_handle(), SW_HIDE);
    ShowWindow(get_handle(), SW_SHOW);

will still make the icon disappear. This works both in a Win32 app and in an unpackaged WinUI3 one, but only with default icons. Doesn't work once the icon has been set up through SetIcon() / WM_SETICON. Doesn't work for packaged.

This is not an acceptable solution, but I believe there must be a more delicate way to redraw the title bar. (RedrawWindow for some reason doesn't work here).

And I agree with you that we should not rely on undocumented tricks, so this test is more of an academic interest.

Thank you again for your time!

[DarranRowe]

Interestingly, on Windows 11, hiding the window then showing it again also works for packaged if the icons are set to default.
This is why I have stated that there are unknowns here. On my end, the packaged applications run identically to unpackaged applications and I have been using the default project templates for WinUI 3 to test things out there.