[DllCall] Pseudo wrapper for common DLL's

[Cuadrix]

Bare bones pseudo DllCall wrapper for functions in common Dll's; user32.dll, kernel32.dll, comctl32.dll, gdi32.dll

How to use?
Place dllcall32.ahk file somewhere, preferably in a library folder, and include it with the #Include directive.
Now you can use the specific function without wasting time typing DllCall("......", ..., however you will still need to type in the data types.

Example

Code: Select all

#Include <dllcall32>
MessageBox("Ptr", 0, "Str", "Hello", "Str", "Caption", "UInt", "0x00000004L", "Int")

Downloads

dllcall32.ahk

(313.57 KiB) Downloaded 99 times

[coffee]

Code: Select all

GetKeyState(Args*){
	Return DllCall("GetKeyState", Args*)
}

SendInput(Args*){
	Return DllCall("SendInput", Args*)
}
SendMessage(Args*){
	Return DllCall("SendMessage", Args*)
}

Sleep(Args*){
	Return DllCall("Sleep", Args*)
}

SetTimer(Args*){
	Return DllCall("SetTimer", Args*)
}

PostMessage(Args*){
	Return DllCall("PostMessage", Args*)
}

BlockInput(Args*){
	Return DllCall("BlockInput", Args*)
}

You don't see any issues at all of including a non-namespaced library with these function definitions? like none whatsoever?

[Cuadrix]

Thank you. Forgot about that. Gonna modify the script a little.

Edit;
Modified it so namespaces don't conflict with existing Autohotkey functions.

[burque505]

Cuadrix, thank you, that was obviously a LOT of work.
Could I trouble you for an example of using DLLCall_Wrapper.ahk? So far for me it crashes AHK every time. A file gets created in the scriptdir with the name ".ahk" (no file name, just the extension).
Regards,
burque505

[Cuadrix]

It's pretty simple actually. You just run the script and a selection window will pop up, now you just choose your Dll that exports out functions such as user32.dll or advapi32.dll, and then it will create an .ahk file with the name of the original Dll.
It should also work for custom Dll's, but I haven't tested.

I haven't had any crashing issues with the script, but then again I haven't tested it on any other PC's.
Might I ask what version of Autohotkey you are using (32-bit / 64-bit - Unicode / Ansi)? Is your PC 32-bit or 64-bit?

Edit;
Tested it with another 64-bit PC with 64-bit Unicode build of Autohotkey, and it works just fine.

[burque505]

Thanks, Cuadrix. I'm running Win7 Pro 64-bit, AHK 1.1.30.03. I tried it with both the U32 build and the U64 build, both crashing. I'll report back when I get a chance to try it on a Win10 machine.
Once I eventually have the *.ahk file produced by DLLCall_Wrapper.ahk, could you give me an example of how I might use that file?

EDIT: Working fine on Win10 64-bit, same AHK version. Tried it with user32.dll. The usage is clear when I examine the script, thank you! I'll try it on some other DLLs and report back.
Regards,
burque505

[Cuadrix]

Once you you eventually get the .ahk file, you just do the same as I describe above; Include it in your script with the #Include directive, which after you can just use the name of the function instead of typing DllCall("Name of function", params...)
The wrapper expects the Dll file to be in a consistent path, meaning that if you move the Dll from where it was "referenced" by the script, It will no longer work.
I'm modifying the script a tiny bit more to make it more flexible regarding that.

[burque505]

Thanks, Cuadrix, turns out my permissions are hammered on the Win7 machine. I'm running subinacl on it now to try to reset everything to default permissions.
Regards,
burque505

[Cuadrix]

turns out my permissions are hammered on the Win7 machine. I'm running subinacl on it now to try to reset everything to default permissions

Uh. I see, glad you found the source of the crashing.

I edited the script for better compatibility with custom Dll's.