DllCall - Str vs AStr and WStr Topic is solved

[Cuadrix]

Can I just use Str instead of AStr and WStr when "functions only accept a specific type of string" ?
Or should I always use AStr for LPSTR, LPCSTR and WStr for LPWSTR, LPCWSTR ?

[just me]

If a function has an ANSI FunctionA as well as an Unicode FunctionW version you normally can use Str because AHK will call the appropriate function version.
If a function always requires a specific type of string, you have to use AStr for ANSI strings with AHK Unicode and WStr for Unicode strings with AHK ANSI or if you want the script to run with both AHK versions.

[swagfag]

followup: can an ANSI build of ahk DllCall Unicode functions(...W)

[just me]

Of course, but you have to specify the FunctionnameW in the DllCall() explicitly.

[swagfag]

huh, i thought ansi could only call ansi and generic, while unicode could call ansi, unicode and generic
idk if theres a point in ever calling the unicode functions if ure running the ansi build(talking about winapi primarily)
but thanks for the info @just me

[just me]

For example:
CreateFileA -> lpFileName

In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\?" to the path. For more information, see Naming Files, Paths, and Namespaces

AHK ANSI:

Code: Select all

FileName := "\\?\D:\very long path"
FileHandle := DllCall("CreateFileW", "WStr", FileName, ...)

[Cuadrix]

One more question occurred;
Is it actually necessary to use UIntP for a DWORD* ?
Can I not just use Ptr for all pointer related arguments even if the value which the pointer points to is updated by the function?
Or is there something preventing this working out?

And yes, I know that Ptr is generally used for handles and pointers to arrays and structures.

[just me]

DWORD* expects a pointer to memory holding a binary UInt value. If you want to use Ptr for the type, the script will look like

Code: Select all

VarSetCapacity(UInt, 4, 0)
NumPut(42, UInt, "UInt")
DllCall("TheDllFunction", "Ptr", &UInt, ...)

And if the function updates the value you need something like the following after the DllCall()

Code: Select all

RetVal := NumGet(UInt, "UInt")
MsgBox, The new value is %RetVal%

Using UIntP makes things a bit easier, because AHK handles most of it automatically (converts the numeric string in UInt to a binary value and restores the returned binary value as numeric string)

Code: Select all

UInt := 42
DllCall("TheDllFunction", "UIntP", UInt, ...)
MsgBox, The new value is %UInt%

[Flipeador]

@just me Does this also apply to v2?, since integer numbers are stored as Int64. [Possibly already been answered in some post]
I'm not good enough with bit-level operations (not yet).

Note: There is a topic related to questions about DllCall.
https://www.autohotkey.com/boards/viewtopic.php?f=76&t=6147

[Cuadrix]

Ah, that makes sense. Thanks for clarifying @just me

[just me]

@Flipeador: I don't use v2 as yet. I believe to have read that &Var will create a pointer to a binary number buffer for variables of type integer or float in v2, but I cannot find it just now.

[Helgef]

@Flipeador

Does this also apply to v2?, since integer numbers are stored as Int64.

In v2 you can do 'ptr', &myInt, but you'd need to use numget (or << / >>) if you need to sign extend the number.

&MyVar retrieves the address of MyVar's contents in memory, where MyVar is a user-created variable. MyVar's contents can be a string, a 64-bit integer, a 64-bit floating-point number, or an object.

or use bufferalloc(), varsetcapacity is deprecated. Using 'type*' would be the better general option.

@swagfag, the A and W suffixes is just a naming convention to indicate the type of strings the function uses, as long as the calling convention is supported you can call any function you like regardless of how it handles strings. Just use str vs astr and wstr as just me showed

Cheers.

[Flipeador]

Thanks. Later I'll play with MCode.