4 replies to this topic

[TheGood]

I've noticed this before, but only now am I looking deeper into it.

For some reason, the PathIsRelative API needs the appended A in order to work (I guess otherwise it calls the Unicode version?). This bug does not occur on ANSI AHK_L.

sFile := "file.dat"
MsgBox % DllCall("shlwapi\PathIsRelative", "str", sFile) ;Won't work
MsgBox % DllCall("shlwapi\PathIsRelativeA", "str", sFile) ;Works

[Laszlo]

PathIsRelativeA is the name of the ANSI version of the function in the Windows shlwapi.dll. What you describe is not an AHK problem, but the naming convention of the Windows system functions.

[TheGood]

I'm well aware of the naming convention. But I was under the impression that you should never append the letter yourself (A or W) to make the code more portable. Is that not so?

The fact remains that AHK_L does not have this problem, while vanilla AHK does. Wouldn't that make it an AHK bug?

[Laszlo]

No, it is just a missing convenience feature from AHK, not a bug. If you want, you can call the wide char version of the dll function, or the ANSI version, and manipulate the input/output format yourself, like calling conversion functions, extracting a word, etc.

[SKAN]

I was under the impression that you should never append the letter yourself (A or W) to make the code more portable. Is that not so?

 DllCall

DllFile may be omitted when calling a function that resides in User32.dll, Kernel32.dll, ComCtl32.dll, or Gdi32.dll. For example, "User32\IsWindowVisible" produces the same result as "IsWindowVisible". For these standard DLLs, the letter "A" suffix that appears on some API functions may also be omitted. For example, "MessageBox" is the same as "MessageBoxA".