Custom Query (3933 matches)

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

*it is: [optional] If True then for 2D array above parameters refer to rows; if False (default) above parameters refer to columns

*should be: [optional] If True then for 2D array above parameters refer to columns; if False (default) above parameters refer to rows

The example works correct hence the description has a glitch ;-)

Ok. So this has occurred on two machines that I have installed the newest version of autoit and scite for autoit on, and this occurs right after the installation. My process: I uninstall the beta version of autoit, download the most up-to-date production version of autoit, run the installer, uninstall the previous production version of autoit from the installer, proceed to install the latest production version of autoit. Then, I use the AutoITupdate script in Autoit's "extras" folder to download and re-install the beta. I then download the latest version of scite for Autoit and install it (I have done this both with and without uninstalling it). The result? One of these installers is completely wiping out all of the values in the PSModulepath environment variable. How do I know? Take a look at the only two remaining values that are configured for the environment variable (see picture 1 since I can't post image links due to the fact my submissions keep getting blocked as spam). All I can say is thank god I had backups of my environment variables and I was able to restore them. I don't know which autoit product is doing this, but please fix it. This is what greets those who open powershell after installing the faulty autoit product (see picture 2 since I can't post image links due to the fact my submissions keep getting blocked as spam). For those who are not familiar with PSModulepath, this is what it should look like (restored from backup) (see picture 3 since I can't post image links due to the fact my submissions keep getting blocked as spam).