id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
1362	_WinAPI_WindowFromPoint() broken on x64	Ultima	Valik	"Indeed, I've seen #974, but I think the problem I'm addressing is different.

Currently, if you run _WinAPI_WindowFromPoint() under an x64 OS, you'll notice that the function always returns a handle to the desktop window. This can be verified by testing the example script for _WinAPI_WindowFromPoint() -- you'll find that the tooltip almost always shows the same handle.

Why is it happening? The problem seems to be in the way the parameters are passed to the user32.dll. WindowFromPoint actually expects a 64-bit POINT structure to be passed by value, but _WinAPI_WindowFromPoint() passes the two parameters. This in and of itself should be fine, as explained [http://support.microsoft.com/kb/138518 here], but I suspect (though don't know for a fact) on the x64 build of AutoIt, one of the 32-bit parameters used as components for the coordinates ends up getting padded into a 64-bit integer, and the other one ends up getting thrown out.

To work around this, I ended up recasting the passed $tPoint parameter from ""long;long"" into ""int64"", and passed the value from that casted struct into DllCall instead. From my basic tests, the result is that this properly fixes x64 support, while maintaining x86 support.

Here's the patched code:
{{{
Func _WinAPI_WindowFromPoint(ByRef $tPoint)
	Local $tPointCast = DllStructCreate(""int64"", DllStructGetPtr($tPoint))
	Local $aResult = DllCall(""user32.dll"", ""hwnd"", ""WindowFromPoint"", ""int64"", DllStructGetData($tPointCast, 1))
	If @error Then Return SetError(@error, @extended, 0)
	Return $aResult[0]
EndFunc   ;==>_WinAPI_WindowFromPoint
}}}"	Bug	closed	3.3.3.0	AutoIt	3.3.2.0	None	Fixed	WindowFromPoint x64