TrayTip can show your current tray icon in the notification by adding 4 (NIIF_USER) to the options. This should work on any AutoHotkey version running on XP SP2 or later, but hasn't yet been noted in the AutoHotkey documentation. Note that if you change the tray icon after calling TrayTip, it should not affect the TrayTip (so you can show different icons).

On Vista and later, adding 0x20 (NIIF_LARGE_ICON) will show a large version of the icon. However, it requires the program to specify the icon, so only works with the stock icons (options 1, 2 and 3) in current AutoHotkey versions.

On Windows 10, the "toast" notification always shows a large icon even if this flag isn't set, but if the flag is not set, it upscales the small icon (usually 16x16) to the large icon size (usually 32x32), so looks terrible. If you don't specify an icon option, it uses the application icon (whereas previous OS versions would not show any icon).

New to this test release:

If TrayTip option 0x24 is used, the large version of the tray icon is shown in the notification.

On Windows 10, the 0x20 option is added automatically. If no icon option was specified, the current executable's main icon is used (not necessarily the tray icon) - the same icon as before, but the large version.

Testing needed:

General functionality on Windows XP.

Large icon support required targeting Vista in the SDK headers, which changes the definitions of some structs and constants to the Vista versions. This can prevent affected APIs from working correctly on XP. According to my notes, the last time I tried targeting Vista (before reverting it), there were two known issues:

Process Close broke on XP. I fixed it this time.

TrayTip broke on "non-English Windows". I don't have non-English Windows to test on, but this time around I found that it broke TrayTip on XP, and fixed it. (This also fixed TrayTip on Windows 2000 as a side-effect.)

No... "all the criteria" was "general functionality"; i.e. everything. As I tried to explain, the change that requires testing is a simple version number change that may affect many Windows APIs (changed from #define _WIN32_WINNT 0x0501 to #define _WIN32_WINNT 0x0600). I don't know precisely which APIs it affects, except for the ones that I have already fixed and don't need testing for (Process Close and TrayTip).

How revert-able is the change?
If we are worrying about something which may break in an EOL product, has a scope too big to be able to get any semblance of coverage, and it is potentially revert-able, why sweat?
Surely at some point a line in the sand has to be drawn, or do you plan to support XP for all features in perpetuity?

If it breaks and someone can give a sample script and language, then surely you could test that (Surely you can set your version of windows to any locale setting, it's just inconvenient and impractical to test loads of them) and potentially find a fix.

Who's worried? Whatever the outcome, it matters little to me. I just provide XP users a chance to test before the change is merged into the stable branch.

The change cannot be reverted without also reverting the TrayTip enhancement, and will not be reverted even if some commands are completely broken. If there are problems, it will be due to some API that has changed slightly between XP and Vista and needs patching to get it to work again.

I'm playing around with this a bit and I think TrayTip is working now on Win10 in that the icon looks better. But its hard to tell...

With version 1.1.24.00, the TrayTip command uses the tray icon as you state but scales up the small icon to a large icon size, rendering the quality poor and shows (mine at least) with a black background. Running the same script with this test build instead shows the AHK icon when using the TrayTip command (though I do not see any quality degradation or the black background as previously).

I may just have misunderstood exactly what changes were taking place and how, but was the icon that is used supposed to have changed (other than the size)?

kczx3 wrote:With version 1.1.24.00, the TrayTip command uses the tray icon as you state but scales up the small icon to a large icon size

This is not the behaviour that I saw, nor what I described. Without the NIIF_USER (4) option, my Windows 10 system shows the application icon, which is not the same as the tray icon if you have used Menu Tray, Icon. (This was prior to the "anniversary edition" Windows 10 update; I have not tested since that was installed.)

In v1.1.24.00, TrayTip does not provide an icon; the system just uses either the application icon or tray icon depending on the options and version of Windows. In this test build, TrayTip provides an icon only if you specify the large icon flag (0x20) or Windows 10 is detected. It uses a custom tray icon only if you specify option 4, since that is consistent with the previous behaviour I observed.

I see. I added 0x04 to the options on my Win10 system using the test build and it now shows the tray icon. Otherwise, it just shows the ahk.exe icon (green H). I guess I just don't technically understand why using v1.1.24.00 uses the tray icon (not the application icon) without needing to specify the option. Either way, it doesn't really matter to me as long as it's documented as such. Thanks!

It's over a year since Windows 10 was released, I finally do something about the blurry icon, and Microsoft have gone and changed it in the latest update.

On Windows 10.0.14393, Shell_NotifyIcon now shows a small icon by default (but TrayTip in this test release overrides it).

It still shows an icon by default (even though older versions of Windows do not), but it now shows the tray icon, not the application icon.

I could be mistaken, but I think the large icon is also blurrier. That is especially strange since I usually use 125% DPI and would have expected the icon to be scaled already. With DPI at 100% the icon appears to be about 40x40 on my system instead of the usual 32x32. Can anyone here confirm the size on this or the previous Windows 10 build?

I think the notification layouts have changed slightly as well. TrayTip with large icon shows the program name - I don't think it did that before.

I don't think they thought that through. The icon will be upscaled for virtually every program ever made that provides a large icon to Shell_NotifyIcon.

We can provide an icon of any size (and the system will scale it), but I don't think it's possible to ask the system what size is going to be displayed, and there's no telling when or how they'll change it.