Control ID returned by GUIGetCursorInfo when use with overlapped controls

[anonymous]

GUIGetCursorInfo() return an array. Index 4 of that array is the control that the mouse cursor is hovering over, or 0 if none.

When use this function with overlapped controls (control which is placed over another control, at the same position), then the function return the most recently added control!

This returned control is totally useless, since both WinAPI function (like WindowFromPoint()) or AutoIt message handling (OnEvent function, GUIGetMsg()) always return the FIRST created control at that position (since Windows believe that the FIRST created control is at most "front", any control created later should go behind it).

Expected: change this behavior, since it's rarely to have overlapped controls, it have the small change to break current script. Also, I see some script call WinAPI function to provide workaround for this, so a directly solution should be considered.

[BrewManNH]

Post a reproducer script that shows the problem.

[BrewManNH]

I was PM'ed this script that is supposed to show the bug the OP is referring to. Au3Check makes a couple of complaints about it, but I can't tell what it's supposed to be doing in all the nested WinAPI functions that it occurs in. But I figured I should post what the OP thinks demonstrates the problem.

#include <WinAPI.au3>
#include <WinAPISys.au3>

$hWnd = GUICreate(@AutoItVersion)
$idBtn1 = GUICtrlCreateButton("Button 1", 5, 5)
GUICtrlSetOnEvent(-1, "ControlEvent")
$idBtn2 = GUICtrlCreateButton("Button 2", 5, 5)
GUICtrlSetOnEvent(-1, "ControlEvent")

$idLbl1 = GUICtrlCreateLabel("Label 1", 90, 5)
GUICtrlSetOnEvent(-1, "ControlEvent")
$idLbl2 = GUICtrlCreateLabel("Label 2", 90, 5)
GUICtrlSetOnEvent(-1, "ControlEvent")
GUISetState()

; Hover your mouse over the overlapped buttons or labels and press Hotkey
HotKeySet("^{F7}", "MouseOverBug")
HotKeySet("^{F8}", "SwitchMode")

Func SwitchMode()
	Opt("GUIOnEventMode", Not (Opt("GUIOnEventMode")))
EndFunc   ;==>SwitchMode

Func ControlEvent()
	Local $aPos = GUIGetCursorInfo()
	ConsoleWrite(@CRLF & "Clicked control ID (Event Mode): " & @GUI_CtrlId)
EndFunc   ;==>ControlEvent

Func MouseOverBug()
	Local $aPos = GUIGetCursorInfo()
	If (IsArray($aPos)) Then
		ConsoleWrite(@CRLF & "Hover control ID (By GUIGetCursorInfo): " & $aPos[4])
		ConsoleWrite(@CRLF & "Hover control ID (By WindowFromPoint): " & _
				_WinAPI_GetDlgCtrlID(_WinAPI_WindowFromPoint(_WinAPI_GetMousePos())))
		ConsoleWrite(@CRLF & "Hover control ID (By ChildWindowFromPoint): " & _
				_WinAPI_GetDlgCtrlID(_WinAPI_ChildWindowFromPointEx($hWnd, _WinAPI_GetMousePos(True, $hWnd))))
	EndIf
EndFunc   ;==>MouseOverBug

While Sleep(10)
	Local $iMsg = GUIGetMsg()
	Switch $iMsg
		Case -3
			ExitLoop
		Case $idBtn1, $idBtn2, $idLbl1, $idLbl2
			ConsoleWrite(@CRLF & "Clicked control ID (MsgLoop Mode): " & $iMsg)
	EndSwitch
WEnd

[Melba23]

I agree that AutoIt regards the most recently added control as "on top" and that the ControlID value returned by AutoIt's GUIGetCursorInfo function refers to the most recently created control. If you create the buttons with the UDF function (_GUICtrlButton_Create) then the earlier button does indeed take priority as the buttons are outside AutoIt's internal control array.

But I would argue that as AutoIt refuses to action a control in a region where it overlaps another - for the very good reason that it cannot read your mind and determine which control you were intending to action - the matter is entirely moot as you should avoid overlapping controls at all.

M23

[Jpm]

no more info so I close it