Custom Query (3926 matches)

Parameters of type "float" are mangled when passed to DllCallbackRegister() callback functions under x64. The following script demonstrates the problem:

Local $hCallback = DllCallbackRegister("Callback", "none", "double;float;")
Local $pCallback = DllCallbackGetPtr($hCallback)
DLLCallAddress("none", $pCallback, "double", 1234, "float", 1234)

Func Callback($fDouble, $fFloat)
	ConsoleWrite("Double: " & $fDouble & @CRLF)
	ConsoleWrite("Float: " & $fFloat & @CRLF)
EndFunc

The double output is correct. Float output is mangled and changes with each invocation.

DirCreate returns 1 (success) when the path is longer than 255 characters. However the path created is truncated to 255 characters, thus creating some unknown shortened path. This occurs even using correct unicode long path notation:

\\?\C:\some\really\long\path
or
\\?\UNC\server\share\some\really\long\path

DirCreate should either return 0 (failure) when a normal path is given that is longer that 255 characters, or it needs to actually create the correct extra long path when proper unicode long path notation is used.

See ​http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx for reference.

In this function, the first line checks if the window handle passed matches the rich edit classname. It should not do this as the window handle passed to this function should never be a rich edit control, rather the parent window. It also has the dubious problem of calling this function with a blank classname on the first call to _Create (the variable is not yet initialized) so it SUCCEEDS. Only subsequent calls fail, return a handle of 0, and an undocumented error code of 1. To fix, revert this handle check to something sane, like IsHWnd() or WinExists(), and document the error code.