Custom Query

Said function tests for 0xFFFFFFFF (which equals INVALID_HANDLE_VALUE under 32-bit only). Should probably be changed to a constant and use the value -1 (or perhaps (Ptr("")-1)) for 64-bit compatibility. I've also attached a corrected version of WinAPI.au3. Changes are on lines 28 and 980.

See this post: ​Intel Software Network Blogs for slightly more information if you need it.

Considering the discussion a few weeks ago about BitShift being a *signed* shift in AutoIt, shouldn't the _WinAPI_HiWord function, and indeed all UDF functions where a DWORD needs to be split into hi and lo words by any means (the _WinAPI_HiWord function or manually via BitShift), be changed accordingly:

Func _WinAPI_HiWord($iLong)
    Return BitAND(BitShift($iLong, 16), 0xFFFF)
EndFunc   ;==>_WinAPI_HiWord

While an error likely won't occur very often, this is the only way to assure we are getting the correct hi word result, unless AutoIt changes the way it does BitShift to be unsigned.

I understand if you want to forgo this change in favor of waiting until AutoIt's internal number handling is revamped, but it is a viable patch in the meantime.

When calling the Date UDF functions _SetDate and _SetTime with the correct parameters it errors with the following message: ############################### C:\Program Files\AutoIt3\Include\Date.au3 (1341) : ==> Subscript used with non-Array variable.: Return Int($iRetval[0]) Return Int($iRetval ^{ERROR ->15:25:25 AutoIT3.exe ended.rc:1 ############################ This can be recreated using the script in the help file. Think the return should be "Return Int($iRetval)". This seems to stop that from happening.}