Question about IconDll_XXX.bar= entries in wincmd.ini

[petermad]

2Ghisler

I have a lot of different entries in the [Buttonbar] section of my wincmd.ini file. There is one IconDll_XXX.bar= for each .bar file that I have had opened (where XXX is the name of the .bar file).

My question is - what are the purpose for these entries - TC can only use 1 iconlib for all bars at the same time, and that is always either wcmicons.dll or the one set by DefaultLib=

If I delete all IconDll_XXX.bar= occurrences manually and start TC, then the correct iconlib (defined by DefaultLib=) is loaded anyway, and TC immdiately sets IconDll_XXX.bar= for the visible icon bars, but why?

Is it for a future possibility to set a different iconlib for each .bar file?

Or is it for TC to be able to compare IconDll_XXX.bar= and DefaultLib= when a bar file is opened to check whether the icons have to be re-read or if they can just be read from the .br2 file. If that is the case, then why is it the file info description that is used for IconDll_XXX.bar= and not the file name? - there can only be one file with a particular name, but several different files can have the same file info discription.

[ghisler(Author)]

TC remembers which icon library was used to create the .br2 cache file. I can't save that to the cache file itself, because it would make it incompatible with older TC versions.

[petermad]

2ghisler(Author)

Well, that was what I thought. But since TC remembers the file info description and not the file name, there is a possibillity for fail if two or more dll files have the same file info description.

I tried it - I made a copy of wcmicons.dll -> wcmicon3.dll and provided it with the same description as wcmicon2.dll. I then used wcmicin3.dll while opening a few diffrent .bar files. Thereafter I switched to wcmicon2.dll - only the current .bar file got updated, the others didn't, but kept using wcmicon3.dll. That's why I think it would be better if TC remembered the file name and not the file info description.

[ghisler(Author)]

Yes, it's the job of the person who creates such a dll to create a unique description. TC remembers the description so it can recognize when e.g. wcmicons.dll is replaced by wcmicon2.dll.

[petermad]

it's the job of the person who creates such a dll to create a unique description.

But will that always happen? If the creator uses a filename that is not unique, the user - when installing - will be warned about overwriting the existing file and can choose not to, but he will not be warned if the description happens to already exist.

What is the benefit of basing TC's recognition on the description in stead of on the file name?

[ghisler(Author)]

Because the file name can be changed, and the dll stays the same or changes. But the content can be changed although the name stays the same. So the only reliable difference would be the content. But reading the entire dll would be too slow.

[petermad]

OK - there are pros and cons for both approaches.

[MVV]

I think that DefaultLib and IconDll_* parameters should store same value types (file name or file description or whatever else). Changed file name is the same problem for all of these parameters.

And I don't think it is a good idea to rely on library resources, I think it would be better to remember filenames. User simply should keep in mind that he will have to re-select icon library (or TC will have to recreate BR2 files) when library is renamed.

[ghisler(Author)]

Defaultlib is chosen by the user, the others are created by TC for caching purposes. Some admins may not want the user to change the icon library, but TC still needs to write this cache value.