- Status Assigned
- Percent Complete
- Task Type Bug Report
- Category Application
-
Assigned To
Admin - Operating System All
- Severity Low
- Priority Very Low
- Reported Version Development
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#304 - Button icon bug: not visible at run time
With the attached .kxf file, the icon is visible at design time but not at run time. The icon is number 0 in shell32.dll. Other icons in shell32.dll work OK. Icon 0 in moricons.dll also does not work.
This may be an AutoIt error. If it is, is there a way for Koda to work around AutoIt’s bug?
You will need to change the drive letter for the .dll file. Perhaps one day .kxf files will store @SystemDir rather than ?:\WINDOWS\System32.
A bit weird thing. This is what written in the Autoit docs:
So, this should work just like GUICtrlCreateIcon. Negative numbers - number of icon in the file.
But I not understand what "Otherwise -1" mean. What "-1" do here - clear icon? Stupid if so, since it's break "1-based index" rule.
I do not understand either, (but then I don't always understand what is written in the AutoIt doc, even though my first language is English!). Would you like to report this in Trac?
A work-around for Koda: rather than generating
generate
This could be done for all icon dlls in which icons are not named.
BTW I note that I chose Image 0 in Picture Editor | Images in File and got
Should Images in File be 1-based?
This is correct. Koda not parsing resource names, and refer icons by index only. So, in Autoit, with "negative 1-based index", actual icon indexes will be:
0 →
→
Using
instead
not quite correct, since literal name of resource can be anything, and passing string "1" you can get empty icon.
In any case, this is looks like a bug in Autoit's Button implementation, since GUICtrlSetImage work fine with Icon and TreeView.
So should the Koda doc for Picture Editor say: "Due to a deficiency in AutoIt, it is not possible to use the first icon in an icon .dll file" ?
Is there really no work-around?
Is the literal name of the first icon in shell32.dll actually "1"?
Is it possible to implement the following logic:
BTW I used your enumicons.au3 (from the AutoIt distribution) in my sleuthing. Thank you.
I think we can use numeric 0 in case where should be -1. While it wrong, it's should work. I don't want messing with names.
BTW, enumicons.au3 in Autoit package is incorrectly working with resource names. I once did the right version, it was placed in distribution, but later Jon removed it with the reason "it's too complex for example". While that right, bundled version get wrong example of working with literal names.
Correct version is here. And this topic just for the story.
Thanks.