Custom Query (3927 matches)

When a form control is contained in the pixel footprint of another larger control the 'Finder Tool' sees the larger control and its associated info but cannot see the smaller contained control.

Simple case to illustrate problem: Build a Windows Form app and create a form with a small button on top of a larger button. When the app is run both buttons are accessible. Call up Finder Tool. The Finder Tool will see the larger button but cannot see the smaller button.

Problem: The smaller button is in the list of Child controls for the form, but the Finder Tool control geometry matching test returns info for the larger button. Even though the smaller button is on the list of the forms Child controls, the Finder Tool returns the wrong match information.

I am currently running AutoIt (64) version 3.3.14.2 on an up-to-date Windows 10 Home laptop (Dell Inspiron 5759).

Run AutoIT Window Info (64). Open any application window Move it until AutoIT Window Info shows an X value for Position of 0. The window will actually be 7-8 pixels to the right of 0. Now maximize the application window. Position will be displayed as -7,-7

When a window is maximized, the upper left corner should have Position 0,0

Note that using WinMove and giving the coordinates 0,0 will also incorrectly position the window.

The _WinAPI_GetGUIThreadInfo does not return correct information for the caret bounding rectangle, in elements 7-10 of the return array. That can be observed using the demo program from the help documentation for _WinAPI_GetGUIThreadInfo, or the following block

#include <WinAPISys.au3>
Local $iPID
Local $aInfo[11]
$aInfo = _WinAPI_GetGUIThreadInfo(_WinAPI_GetWindowThreadProcessId(WinGetHandle('[ACTIVE]'), $iPID))
MsgBox(0, "_WinAPI_GetGUIThreadInfo Bug", _
       "Active window caret: "&$ainfo[7]&" "&$ainfo[8]&" "&$ainfo[9]&" "&$ainfo[10] & @CRLF & _
       "Caret window "&$ainfo[6]&" incorrectly equals caret x pos "&$ainfo[7])

The bug is a straightforward error in the UDF, referencing the wrong element of the DLL return struct.

	For $i = 1 To 4
		$aResult[6 + $i] = DllStructGetData($tGTI, 6 + 2, $i) ;<-- Second arg should be element 9, not 8
	Next

Also noted, for strict compliance, the $tagGUITHREADINFO DLLStruct should be properly declared with struct to ensure alignment of the rcCaret rect.

While a slightly more verbose DLLStruct definition, spelling out each of the rect members results in simpler code to copy the data out of the struct (and solves the bug by simply getting rid of the need for the loop with the buggy reference).

Func _WinAPI_GetGUIThreadInfo($iThreadId)
    Local Const $tagGUITHREADINFO = 'dword Size;dword Flags;hwnd hWndActive;hwnd hWndFocus;hwnd hWndCapture;hwnd hWndMenuOwner;hwnd hWndMoveSize;hwnd hWndCaret;struct rcCaret;long left;long top;long right;long bottom;endstruct'
	Local $tGTI = DllStructCreate($tagGUITHREADINFO)
	DllStructSetData($tGTI, 1, DllStructGetSize($tGTI))

	Local $aRet = DllCall('user32.dll', 'bool', 'GetGUIThreadInfo', 'dword', $iThreadId, 'struct*', $tGTI)
	If @error Or Not $aRet[0] Then Return SetError(@error + 10, @extended, 0)

	Local $aResult[11]
	For $i = 0 To 10
		$aResult[$i] = DllStructGetData($tGTI, $i + 2)
	Next
	For $i = 9 To 10
		$aResult[$i] -= $aResult[$i - 2]
	Next
	Return $aResult
EndFunc   ;==>_WinAPI_GetGUIThreadInfo