Problem with 256-color icon files (.ico) in Windows

[TheIconoclast]

A decision was recently made here on the project to switch from using a DLL for a large (>500) set of "map icons" to using a folder full of .ico files (making it simpler for users and us to add new icons). The icon DLL was built using MS Visual Studio 6.0 on a Windows 2K machine. Not being a glutton for punishment, I tried simply pulling the intermediate .ico files from the DLL project and loading them using WbIcon fromFile:size:.

The problem I'm encountering is within CgWinICOFileFormat. This class retrieves a header from the .ico file and reads some property data (dimensions, color depth, offset). It appears that MS standard 256-color icons do not follow the same standard as CgWinICOFileFormat. Every MS 256-color icon I've mucked around with (including MS-built ones like MSN.ico in the MS Office folder) have a 0 at the location where CgWinICOFileFormat is expecting to find the number of colors. 16-color and 2-color icons I've created do have the color depth property assigned properly.

This problem rears its head in CgWinICOFileFormat>>loadInfoHeader:iconHeader:. I'm currently working around it by testing if numColors is 0 and setting it to 256; this does not seem like the best solution. Manually tweaking the .ico file with a hex editor fixes that problem in Smalltalk, but makes it unrecognizable to the Visual Studio icon editor.

Are there any thoughts as to a (better) workaround or long-term fix to this issue?

Brian O'Connell
Simulation Domain
Joint Analysis System (JAS)

[nmongeau]

Going through Google I found several sources indicating that when the byte stored where CgWinICOFileFormat reads the number of colors is 0, it means 256 colors (for example: http://www.daubnet.com/formats/ICO.html).

Normand

[TheIconoclast]

With that being the confirmed case, it seems to me that CgWinICOFileFormat may be in need of a tweak. Something to the effect of...

Code: Select all

CgWinICOFileFormat>>loadInfoHeader:iconHeader:
...
numColors := iconHeader at: 3.
numColors = 0 ifTrue: [numColors := 256]..
...


Instantiations folks?

Brian

[wembley]

Brian -

Your code is a good work-around for this problem. The actual fix is a bit more involved, but I doubt you would ever notice the difference in your usage scenario.

I will open a defect report and schedule it for the 7.5.2 fixpack.

[crenz]

Is it planned to add support for true-color icons? So far I haven't been able to use those. That would be rather helpful to achieve a more modern UI look.

[wembley]

We currently do not have true color (32-bit) icons in our development plan. Can you expand on your need for this support?

Regards, John

[crenz]

One important application for us is using overlay icons, e.g. for version management. Think of tools like TortoiseSVN or Eclipse that display the version status right on top of the icon's item. For this you need to use either 16 color icons (overlayed with 8-256 color icons) or true-color icons.

256 color icons use a custom palette. If you were to overlay two 256 color icons, the results look awful unless you do palette transformations (and even with that, they look ugly). Being able to use 32 bit icons would make this much more easy. It is not feasible to pre-render all possible overlay combinations, because for some use cases, we even use two overlays (to indicate different statuses), making this a O(l*m*n) problem resulting in thousands of possible combinations.