There are only around 36 icons in the library, but this count comes up with over 8000.

This used to work in a former version of ahk, but I don't remember which one. Apparently the function was changed and doesn't inspect the dll the same way?It doesn't have this problem with every dll. But I am making my own dlls, just like I've done for years. Basically, I just use a C compiler to create the dll with icons in an .rc file. That .rc file looks like this:

I use the icons from this dll for all the ahk GUIs with no problem. I've only got issues with this function and it's counting results in occasional dlls.Can someone help me out? I've attached my dll in a zip file.

All I'm trying to do here is to get a count of the number of icons in the dll....

[update]Okay, so I figured this out:

This used to work - in ahk version 1.1.22.00 unicode 32-bit (of course, you didn't have LoadPicture() then - so you have to use the other code I have here:)

BUT, this same code does not work in hak 1.1.24 - for my dll (attached) it does not stop counting.

What used to work, worked in ahk, but with the advent of LoadPicture, I think something in ahk changed.

[Problem Understood (not resolved, but understood]There was indeed a change in ahk with version 1.1.22.05: "Fixed icons which have non-numeric IDs loading with sub-optimal quality." And with this change, the code now rejects icons with an index of 0.This is from the sourcecode for that version.

enum_data.result =-1; //Return value of -1 indicates failure, since ID 0 may be valid.` was changed to `enum_data.result = NULL; // Zero is probably not a valid integer ID; I think it would be compiled as "0"(string).

So, we see in the sourcecode that 0 is rejected as a valid index.

Now, what happens is that when we try to count the icons in the dll, ahk never stops counting. So I think we should fix ahk.

It looks like in version 1.1.22.05 the default behavior for invalid/unfound indices was changed from returning -1 to 0, with the comment that "Zero is probably not a valid integer ID". Your dll has an icon/group at index 0, so instead of failing it is defaulting to that. If you remove the resource at index 0 (either by recompiling or using a tool such as Resource Hacker) everything starts working again.

Here's the commit and line that introduced this new behavior. I now believe this to be a bug, as your dll demonstrates that 0 is, if not a valid index, a usable index that may be encountered.

There are only around 36 icons in the library, but this count comes up with over 8000.

That is because you are not deleting the handles and AHK is hitting the maximum GDI handles it will handle, I guess.Insert DllCall( "DeleteObject", "Ptr",Handle ) and it will loop forever.

It doesn't have this problem with every dll. But I am making my own dlls, just like I've done for years. Basically, I just use a C compiler to create the dll with icons in an .rc file.

Bad idea. I tried your DLL. ID:0 is stored as a number while it should be stored as a string.Either change your method of creating DLL or don't use ID:0 with your resource compiler.No windows API function can tell us whether a Resource ID is stored as a string or number.You have to open the EXE/DLL and parse resource section to find it out.My DllRead() fails to read ID:0 from broken.dllThis is because FindResource() tries to locate a string named 0 while your compiler had stored it as a number.

Here is some test code for you:The first icon of PhotoViewer.dll is ID:0 stored as a stringSee the second parameter of LoadImage(), which is "Str","0"

Now, you said, "That is because you are not deleting the handles..."Okay; I didn't realize I would have to delete handles that were created via an autohotkey command. I know to delete handles with DLLcall - but I haven't been using DLLcall - I've been using the ahk command called LoadPicture() with IL_Add()About not deleting handles, I don't have to delete the handle if I overwrite the handle, right? Isn't that the same thing? In the end, there ought to be only the last handle left over.

I didn't have any problems pre-ahk 1.1.22.05 because it would start with resource 0.

The .rc file won't compile if I wrap the numbers in quotes to make them strings. The compiler says, "warning: Unrecognized or misplaced token: "string".

However, if I don't use 0 and I use 1 instead, THEN it works - so I don't think it has to do with the numbers - just the index. It worked in previous AHK before the command was modified to not regard 0 (see GeekDude's comment above).

It's true, I can recompile my DLL without using 0 for an index. But there are other DLLs that use 0 for an index, too. I didn't make that up - I was doing what I saw others do.

BTW, the better way is to enumerate a resource list and then parse the list to act on the resources.

That is alright, because IL_Add will delete the handle.BUT: The test snippet you have posted above could crash a machine that is already low on resources. Either delete it out, or insert a DllCall->DeleteObject() within the loop.

I didn't have any problems pre-ahk 1.1.22.05 because it would start with resource 0.

The .rc file won't compile if I wrap the numbers in quotes to make them strings. The compiler says, "warning: Unrecognized or misplaced token: "string".

Then don't use 0.

However, if I don't use 0 and I use 1 instead, THEN it works - so I don't think it has to do with the numbers - just the index. It worked in previous AHK before the command was modified to not regard 0 (see GeekDude's comment above).

You didn't try my test code. Did you? Photoviewer.dll is a Microsoft DLL with ID:0 and AHK has no problem with it.Your DLL is creating the problem.GeekDude might agree with me after knowing that a Microsoft DLL is storing 0 as a string ID.

It's true, I can recompile my DLL without using 0 for an index. But there are other DLLs that use 0 for an index, too. I didn't make that up - I was doing what I saw others do.

What can I say! If you want, I can reconstruct your DLL abiding Microsoft rules.BTW, Did you try your .rc file with ResHacker?

just me wrote:Obviously, EnumResourceNames() as well as FindResource() accept the integer ID 0 as valid.

You are right. Earlier, I had thought it was impossible to parse out a list directly from PE resource directory ( of broken.dll).This Integer ID:0 in broken.dll was (acting like NULL in center of a string) breaking my parsing loop prematurely.I've figured a way to parse past it and it is rather simple.

the rule chosen by Win32 is that if the value is in the range 0..0xFFFF, then the value is treated as an integer; otherwise it is treated as a pointer to a string.

just me wrote:So zero is probably a valid integer ID, even if it should be compiled as "0" (string).

To be sure, I scanned my entire drive C: (Win 7 x64) which had about 21030 DLLs in it.To save time, I limited my FindResource() calls to RT_GROUP_ICON with ResID as "Str","0" and "Ptr",00 results for "Ptr",037 results for "Str","0" as follows:

Dear BGM,I hope the AHK glitch is fixed, but I still suggest you to fix your DLL.. ..and thank you very much for this report. I learnt something new and was able to improve my PE resource parsing code.

Okay, so if I use a starting index of 1 instead of 0 then I have no problems with my dll at all - even though I compile it using integers instead of strings (I spoke with the authours of the compiler that I am using, and they provided two examples, but they both use numbers...). So I don't think the problem has to do with using numbers in my .rc file. The problem is totally about the number of the starting index.

In fact, I don't think that I'm defining any string names for the icons at all, so they just adopt their index for their name (I think).Then, in Resource Hacker, if I look at c:\windows\system32\netshell.dll, the icon section starts with index 1, but in the "icon group" section, there is one at index 0.How can you tell whether the identifier is stored as a number or as a string? It all looks the same in Resource Hacker.

Skan - I'm glad you got something out of this, at least, in reward for your time. And by the way, I DID try your test code right when you posted it...

I don't know whether this is normal behaviour, but it doesn't seem to happen with other 32-bit DLLs from SysWOW64.You should consider to rebuild your DLL.

Edit: Must have been 'one of these days' yesterday. I don't remember what made me believe to see correct results for 32-bit DLLs with AHK 64. I should have known better. AHK 64 does not load 32-bit DLLs with LoadLibrary(). And because this error isn't catched in my test script, a NULL handle is passed to EnumResourceNames(), which 'is equivalent to passing in a handle to the module used to create the current process'. The function enumerates the resources of the AHK exe in this case. This cannot happen in ExtractIconFromExecutable() called in util.cpp to extract the icon. It calls ExtractIcon() if either the DLL couldn't be loaded or the icon couldn't be found in the DLL.

Last edited by just me on 16 Sep 2017, 09:58, edited 2 times in total.

Really, I think the problem is within ahk's function.Look - I have recompiled the DLL exactly the same way but started the index at 1 instead of 0.

In my own DLL there are 37 resources defined, all icons, some with more than one format in the icon. That's why "icons" shows as 47, because it's counting icons in the group, too. But the icon group count is correct.

My dll gives the wrong icon report if I run the script with ahkU64. But it gives all the correct info if run in ahk32 U or A. Yeah, I don't know what the difference is either. I'm compiling the DLL with a 32bit compiler. Even if I start the indexing at 1, Just Me's script gives only 10 icons using ahk64U.

With an index of 1 I basically get the same report as I get with an index of 0. ahk64U gives a different report than the 32bit ahks, but I have no idea why that would be, except maybe that it is a 32bit dll; but that shouldn't be a problem, no?

BGM wrote:Okay, so if I use a starting index of 1 instead of 0 then I have no problems with my dll at all - even though I compile it using integers instead of strings (I spoke with the authours of the compiler that I am using, and they provided two examples, but they both use numbers...). So I don't think the problem has to do with using numbers in my .rc file. The problem is totally about the number of the starting index.

To clarify: Integer ID's should be stored as Integers and String ID's should be stored as String ID... It is Black and White thus far.0 is a special value (falls in the Gray area) that can be stored either as an "Integer" or as a "String".Theoretically, 0 can be stored as an integer, but for practical convenience is should be stored as a string.If your RC compiler doesn't give you a choice to store 0 as a string, either change your compiler or don't use ID:0 in your resource file.

Even if your DLL begins to wok with AutoHotkey, it may not work with a different program as you are creating a "practically" non-standard DLL.Throughout this topic, you want AHK to treat a symptom while I have been suggesting you to cure the disease itself.

SKAN, actually, the whole reason I started this is because I am writing a program that is an icon library viewer... so I actually need to confront the problem of the 0 index. I would test it by viewing my own dll's icons, and that worked until version 1.1.22.05 when I could no longer view my own dll (due to the change in reading the 0 index). I am not the only person to use 0 for an index.

So, yes, I can use the index of 1 and it cures this particular little part of a problem, but doesn't really solve my goal. In the end it's not about my dll at all - my dll was just an example.

BGM wrote:SKAN, actually, the whole reason I started this is because I am writing a program that is an icon library viewer...

Wow.. Super! Me too.

so I actually need to confront the problem of the 0 index. I would test it by viewing my own dll's icons, and that worked until version 1.1.22.05 when I could no longer view my own dll (due to the change in reading the 0 index). I am not the only person to use 0 for an index.

Excellent. I fully stand by you after this explanation.

So, yes, I can use the index of 1 and it cures this particular little part of a problem, but doesn't really solve my goal. In the end it's not about my dll at all - my dll was just an example.

You could've quoted this before... But then I or just me wouldn't have done our tests!

haha! I'm sorry to make so much trouble! I love autohotkey, and you guys are great, too (as long as you don't think I'm just some goon). Sometimes I feel like I'm the butt of the conversation, but don't intend too - just trying to get help to solve problems I can't figure out on my own after hours and hours. You can try out my little viewer if you like: http://www.sspxusa.org/goodies/#iconus It's written entirely in autohotkey except for the dll I use to store it's own resource icons (but I use a ahk script to run the compiler!:)). I actually entered that program in the DC NANY a couple years ago, and have a nice mug to show for it.

Actually, the reason I didn't mention anything before is because this was supposed to be a discussion about a bug in ahk where it was not doing what was expected, not a thread to fix a problem in my code.

BGM wrote:Actually, the reason I didn't mention anything before is because this was supposed to be a discussion about a bug in ahk where it was not doing what was expected, not a thread to fix a problem in my code.

Am I misremembering then, thought that it was in Ask For Help, I usually don't browse Bug Reports. Incidentally this has become a very long thread. I read all threads I have posted in except what's on your mind.