AutoHotkey Community

Hi guys.
So i've been using DllCall for a while, but now i want to use PathRemoveExtensionW() winapi function from shlwapi.dll.
ErrorLevel and A_LastError return 0 which is success. But the contents of the variable are not changed:
It always shows "file.mp3", not "file"

Edit: In Visual Studio with C++ this function always works as expected

You are supposed to pass

A pointer to a null-terminated string of length MAX_PATH from which to remove the extension.

You have passed a pointer to a pointer to a null-terminated string of length 8.

The function will interpret the pointer value as a series of either 4 characters (64-bit) or 2 characters (32-bit).

Sorry, didn't notice that it's "str*". When it's "str" it doesn't yield any result as well.

Fix the space after DllCall (

Xtra wrote: ↑

03 Oct 2022, 01:51

Fix the space after DllCall (

Code: Select all

fileMp3 := "file.mp3"
DllCall("shlwapi.dll\PathRemoveExtensionW", "str", fileMp3)
msgbox % fileMp3

Jeez... i can't believe that was the issue. And it wasn't the first time it happened.
Thank you so much for your help!

@Xtra
Not quite correct, it won't work with ANSI version. The W must be removed from the function name, or added to "str".

teadrinker wrote: ↑

03 Oct 2022, 02:28

@Xtra
Not quite correct, it won't work with ANSI version. The W must be removed from the function name, or added to "str".

Of course it won't work with ANSI version because i explicitly added "W". You can change "str" to "wstr" to make it more explicit or if you want to work it in both cases simply remove "A" or "W" at the end of the function names and use "str" without "A" or "W". That's the way whole WinAPI works

Avtem wrote: ↑Of course it won't work with ANSI version because i explicitly added "W"

Are you sure? Try it with ANSI, but don't forget adding "W" to "str".

teadrinker wrote: ↑

03 Oct 2022, 02:36

Avtem wrote: ↑Of course it won't work with ANSI version because i explicitly added "W"

Are you sure? Try it with ANSI, but don't forget adding "W" to "str".

Yes i am sure. Why do you add "W" if you use ANSI?
"A" - stands for ANSI string
"W" - stands for Wide-character (Unicode string)

If you mix everything up of course it won't work. If you want to explicitly call ANSI version, add "A" suffix everywhere. If unicode - "W". If you want to choose automatically depending on your compiler - don't add any suffixes

Avtem wrote: ↑Yes i am sure.

Just try.

teadrinker wrote: ↑

03 Oct 2022, 02:41

Avtem wrote: ↑Yes i am sure.

Just try.

Why would i try to use the function the wrong way?

To make sure you're wrong. If this is the wrong way, it won't work.

Avtem wrote: ↑Why do you add "W" if you use ANSI?

Why not to work with a unicode string even if i use the ANSI version? Perhaps, I read this string from a file. Are you considering this possibility?

teadrinker wrote: ↑

03 Oct 2022, 02:28

@Xtra
Not quite correct, it won't work with ANSI version. The W must be removed from the function name, or added to "str".

I'm surprised you didn't get an "unrecognized action" error with the space.

Adding "W" just avoids DllCall searching for "PathRemoveExtension" before failing and reverting to "PathRemoveExtensionW" or "PathRemoveExtensionA". Aside from that, I think there is no benefit in this case.

Some functions have three versions: one with "W", one with "A", and one without either. In that case, omitting the suffix will not work as you might expect.

Newer Windows versions allow enabling long path support, which extends the soft limit of MAX_PATH for some functions. This only affects the "W" versions of functions, not the "A" versions, so in that case using the "W" version explicitly might circumvent the MAX_PATH limitation. However, PathRemoveExtensionW is limited to MAX_PATH anyway.

Again, the documentation says to pass a string of length MAX_PATH. fileMp3 := "file.mp3" is not that long, but given what the function does, it is probably fine. Maybe not. Some functions do silly things like zero out the rest of the buffer. Why risk it?

Note This function is deprecated. We recommend the use of the PathCchRemoveExtension in its place.