How do I override the default icon selection algorithm?

Date:	October 5, 2012 / year-entry #236
Tags:	code
Orig Link:	https://blogs.msdn.microsoft.com/oldnewthing/20121005-00/?p=6393
Comments:	13
Summary:	The usual way of loading an icon from a resource is to use the LoadIcon or LoadImage function and letting the window manager's icon selection algorithm decide which image to use based on the images available in the icon, the desired icon size, and the current color depth. A customer wanted to override that algorithm,...

The usual way of loading an icon from a resource is to use the LoadIcon or LoadImage function and letting the window manager's icon selection algorithm decide which image to use based on the images available in the icon, the desired icon size, and the current color depth. A customer wanted to override that algorithm, because the window manager uses the current display color depth to select an image, but they were obtaining the icon for printing purposes, so they wanted to get the highest-color-quality icon rather than the one that matched the screen's color depth. How do you override the default algorithm?

You basically do the same thing the window manager does. As we saw earlier, icon resources are actually stored in multiple pieces. The thing you use to talk about icons is actually the icon directory, which in turn points to a set of images. The first step, then, is to obtain the icon directory.

HRSRC hrsrcIcon = FindResource(hResources,
                     MAKEINTRESOURCE(IDI_MY_ICON), RT_GROUP_ICON);
HGLOBAL hIcon = LoadResource(hResources, hrsrcIcon);
auto lpIcon = static_cast<GRPICONDIR *>(LockResource(hIcon));

You then take the images listed in the GRPICONDIR and apply your custom algorithm to decide which one you like best. (If you want to use the default algorithm, you can call LookupIconIdFromDirectory or LookupIconIdFromDirectoryEx. But if you want to use the default algorithm, then just use LoadImage already!)

When you've found the image you like, take the nId, and that's the resource ID for the RT_ICON.

HRSRC hrsrcImage = FindResource(hResources,
                     MAKEINTRESOURCE(nId), RT_ICON);
HGLOBAL hImage = LoadResource(hResources, hrsrcImage);
auto lpImage = static_cast<PBYTE>(LockResource(hImage));

You can then convert the icon image data into an icon by using the CreateIconFromResource or CreateIconFromResourceEx function.

Comments (13)

Andrew says:

October 5, 2012 at 9:34 am

"If you want to use the default algorithm, you can call LookupÂIconÂIdÂFromÂDirectory or LookupÂIconÂIdÂFromÂDirectoryÂEx. But if you want to use the default algorithm, then just use LoadÂImage already!"

This seems to be erroneous. Both methods use the default algorithm?
SimonRev says:

October 5, 2012 at 9:37 am

The Ex version lets you specify a desired size. But both use the default algorithm for color depth selection.
johnstonj@inn-soft.com says:

October 5, 2012 at 10:29 am

@Andrew: he's saying don't waste time if you want the default behavior of the current color depth – just use LoadImage. But if you need to do something different, then carry on…

In other words, if your custom algorithm == default algorithm, just use LoadImage.
640k says:

October 5, 2012 at 7:13 pm

LoadIcon should have loaded all icons, and DrawIcon/DrawIconEx should have decided which resolution to use. The current architectural choices makes me cringe!

["Why does my 16×16 icon take up a quarter megabyte of memory?" -Raymond]
Klimax says:

October 6, 2012 at 3:24 am

Just a reminder that LoadIcon and co are from time, where RAM saving had high prioirty.
Clipboarder Gadget says:

October 6, 2012 at 4:03 am

Sadly it seems that the LoadIcon algorithm is broken since Vista. On a 150% scale DPI setting it loads always the lower resolution and never the higher. Because of that almost all application icons look blurry on the taskbar if you disable "Always combine" for the taskbar. Only some MS applications dont seem to do that, but only because they provide icons in all kinds of sizes.
640k says:

October 6, 2012 at 1:16 am

If a 0.25mb ico file is compiled into the binary, there's of course no surprise that it will use 0.25 of ram when loading it.

[It's a surprise if you aren't the one who compiled the binary. LoadImage("Notepad.exe", 16, 16) suddenly requires 25x more memory than it used to. A folder in small icon mode would not be able to show more than 4000 files in a directory before running out of memory *just for the icons*. -Raymond]
AndyCadley says:

October 6, 2012 at 2:15 am

@640K: If you always load *all* versions of an icon, there's of course no surprise that it uses lots more ram than if you only load what was actually needed.
640k says:

October 7, 2012 at 5:33 pm

[It's a surprise if you aren't the one who compiled the binary. LoadImage("Notepad.exe", 16, 16)…]

LoadIcon isn't LoadImage. If you don't specify a size (i.e. LoadIcon), then it's a surprise that the whole icon, including all it's resolutions, isn't loaded.

[LoadIcon loads the icon at standard size (typically 32×32). I can't wait for Alex to say "designed without adult supervision." -Raymond]
Giulia Q says:

October 8, 2012 at 1:28 am

Shouldn't pointers to resource data be decorated with const and __unaligned?

[Resource data is 4-byte aligned, so you don't need to say __unaligned unless you have data that requires stricter alignment. You can say const if you want. That wasn't really the point of the article. -Raymond]
bombsoft@hotmail.com says:

October 8, 2012 at 6:30 am

blogs.msdn.com/…/10007461.aspx

Loadicon also sounds like a Transformer.
johnstonj@inn-soft.com says:

October 8, 2012 at 7:10 am

@Clipboarder Gadget: Maybe the offending apps/icons are not DPI-aware? If the app hasn't declared itself DPI-aware in the manifest, Windows Vista/7 will emulate 96 DPI which might explain your behavior.
Clipboarder Gadget says:

October 8, 2012 at 9:59 am

No the programs are DPI-aware.

Even if you take a simple program from Petzolds samples with an icon and make it DPI-aware, Windows will take the 16-sized icon and scale it up even though there is a 32-sized icon.

You can prevent this by calling LoadIconWithScaleDown or ExtractIconEx instead of LoadIcon but most programs don't seem to do that.

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

A "redesign" after 2019 erased thousands of user's comments from previous years. As many have stated, the comments are nearly as important as the postings themselves. The archived copies of the postings contained here retain the original comments.
The blog has changed domains many times and the urls have otherwise been under constant change since 2003. Even when proper redirection has been set up for those links, redirection only works for a limited period of time. For example, all of the internal blog links that were valid in early 2019, were broken by 2020 without proper redirection.
The blog has been under constant re-design and re-theming since its inception. It is downright irritating to deal with a bogged-down site experience as the result of the latest visual themes designed for cell-phone browsers. As of this writing, it is cumbersome to navigate titles with only 10 entries per page. While it is nice that the official site has a search feature, searching using this index (with all titles on a single page) is much quicker (CTRL-F in most browsers).

<-- Back to Old New Thing Archive Index