AutoHotkey Community

Hi,

I have just undertaken some serious exercise resulting from the anger caused by this strange behavior. Thought I should save you some time by describing it here. I am not sure whether it should be defined as a bug, or maybe a bug in the documentation of DllCall (arrest me if I am wrong).

I have a DLL that I am calling using the following code:

This works fine and I learned that the DLL catches the Str argument as LPCSTR.

Then to save some code lines I made the slight change to the following:

This slight change means that the Dll receives a different string from the code above. As I am unable to debug the Dll I cannot give you more details. I am also not allowed to provide the DLL. Sorry for not giving you much to work on.

[ Moderator!: Moved from Bug Reports ]

I'm curious how you reached your conclusion. It's not a bug of AHK. You better move it to Ask for Help section.

Hi Sean,

The dll undertakes a search and when I run the search using the first code bit, it can find the expected string, but if I use the second one it cannot find the string.

I will try to provide more details, but it could take lots of time to retrieve them.

Looks like you're searching NULL character in the string with the above code? Anyway, usually the mysterious suffix W in APIs, like FindStringW means that it's a UNICODE version, i.e., the string should be in UNICODE, but you just passed ANSI string, so the result is unpredictable. First examine if there exists an ANSI version, usually named like FindStringA. If not, you have to convert first the ANSI string to UNICODE string before using in FindStringW.

Hi Sean,

That is a good tip and you are right about the unicode, except for that the two are mixed up FindStringW is in my case the ANSI code, while FindStringA is the Unicode.

The results are not unpredictable as far as I can see (20 trials of each) and the results are consistanly as described earlier.

Isn't it possible that when storing a string in a variable, that the encoding is changed? This is as far as I can see the only explanation for this.

How could I say, I suppose you were just lucky.
There may be a delicate difference between passing string via variable and passing it inline.
If you declared variable in AHK, the variable/string is allocated in Heap, which is unlikely to be polluted much at early stage. On the contrary, if you pass the string inline, I guess that AHK temporarily allocate it in Stack, which is likely already polluted even at initial stage. By pollution, I mean garbage bytes different from null/zero.
So, for example, if you're searching UNICODE NULL, which is double-byte, it's likely to give constant position, just at the single-byte ANSI NULL as the next byte is likely to be null/zero, when passing via variable. But, it is less likely with Stack, i.e., passing inline, so the results can be different each after each trial.

That sound like a reasonable explanation. It sounds like you have undertaken so extensive testing that you are sure about the correctness of DllCall.