UDF's missing @error checks after DLLCalls()

[Ascend4nt]

I've gone through and compiled a list of all standard include UDF's (as of version 3.3.0.0) that are missing @error checks after DLLCall's, where either the return 'array' or a passed structure is accessed after. It's a big list, so I wish you the best of luck in getting this worked out.

*ALSO another problem, many are using ANSI calls rather than Unicode (wide calls). I've marked down as much info regarding this as possible

Note: Some additional details are added for certain functions. Most are only 1 DLL Call, some are more - I commented on some, but there may be more than one DLLCall on some I didn't comment on.

[I'm attaching the file instead because the double underscored functions are being messed up by the issue tracker here]

[Ascendant]

AutoIT UDFs with DLLCalls missing proper @error checks and/or calling ANSI variants

[Jpm]

I don't think we have to check something delivered by standard Windows.

I mean the .dll exists and the function is always inside,
the parameter are those described by MSDN.

So what else to check @error will never be set.

I agree we can have more usage of Unicode than ANSI functions I will check.

[Ascend4nt]

Why are there already checks for standard DLLs then? And why was this part of the change history for v. 3.3.0.0?
"Fixed #517: WinAPI UDF - bad error checking after DllCall()"

I'm taking a guess here that there could be errors 'beyond AutoIT's control' - perhaps a bad DLL exists, or a DLL of the same name but wrong version exists in the same application's running folder. (I've actually seen that happen with psapi.dll).

I know from looking at the previous version that there were standard dll's existing for a few of the WinAPI UDF calls, and they were considered standard on the OS, so why was that ticket completed?

thanks

[Valik]

Replying to Jpm:

I don't think we have to check something delivered by standard Windows.

I mean the .dll exists and the function is always inside,
the parameter are tose described by MSDN.

So what else to check @error will never be set.

I agree we can have more usage of Unicode than ANSI functions I will check.

All calls to DllCall() should be immediately followed by a test of @error. Period. There is no excuse for being lazy in the AutoIt libraries.

[jmichae3@…]

I am trying to make kernel32.dll calls to CreateMutex() (CreateMutexA or CreateMutexU) but no matter what I do instead of getting a HANDLE back (used hwnd) I always get an emoty string for a result. should be getting 0 or NULL or a pointer value. so I tried returning a pointer, which is, after all, what a HANDLE is defined as in VC++. same result. this function works in NSIS but fails totally to work in auto-it3.

#include <GUIConstants.au3>

$kernelfunctioncalltype="" ;"A" or "W" or ""
$hmutex=0;
;-----code to prevent multiple instances. doesn't seem to work.
;-----NSIS code: System::Call 'kernel32::CreateMutexA(i 0, i 0, t "mutex-phonelistGUI-3.0-1.0") i .r1 ?e'
$hmutex = DllCall("kernel32.dll", "ptr", "CreateMutex" & $kernelfunctioncalltype, "ptr", 0x00000000, "int", 0x00000000, "str", "mutexGUI-phonelist-3.0")
$e=@error
if 0 <> $e then

msgbox(0,"error",$e) ;never pops up

endif
If 0==$hmutex OR ""==$hmutex Then

;failed to get mutex. do nothing until closing time. apparently we have succeeded

; MsgBox(0,"mutex",$hmutex)
Else

;got a mutex. another instance is running, so exit.

; MsgBox(0,"mutex",$hmutex)

Exit

EndIf

and yes, @error always is 0 no matter what kernel32.dll function I call. what's the deal with this? somebody please fix. and someone fix the variables so they can handle pointers. at least useably convert it to an int and back!

[anonymous]

these were the rest of the calls at the end of the program. the purpose of the code was to prevent multiple instances of the program from running. however, this part of the code may not be necessary. apparently the NSIS code does not call CloseHandle for some reason, and I do not know what the upshot of this is.

while 1

Case $MSG==$GUI_EVENT_CLOSE

;$result = DllCall("kernel32.dll", "int", "ReleaseMutex" & $kernelfunctioncalltype, "ptr", $hmutex)
;if @error<>0 then
; ;do something
;endif
$result = DllCall("kernel32.dll", "int", "CloseHandle" & $kernelfunctioncalltype, "ptr", $hmutex)
if @error<>0 then

;do something

endif
Exit

[Valik]

What the fuck does any of that have to do with this ticket? It has nothing to do with this ticket, that's what. Post on the support forum next time and read WikiStart before you attempt to use the issue tracker again.

[Valik]

Set as blocking, it needs done before the next beta.

[Valik]

Fixed in version: 3.3.1.2