GUIGetCursorInfo behavior in Windows 8

[corz]

; Under Windows 7, moving the mouse into the input will expand the input to full size
; Exactly the same thing happens in Windows 8.
; Under Windows 7, if I move the mouse along the input, it remains full size and active all the way
; to the end. enabling the user to interact with it, edit, copy, paste, etc..
; Under Windows 8, as soon as I move the mouse over the control /under/ the right hand side of the input
; (the checkbox), the input immediately shrinks back and the checkbox is brought to the front.
;
; The old behaviour is correct.


#include <GUIConstantsEx.au3>

Example()

Func Example()

    ; Create a GUI with various controls.
    local $hGUI = GUICreate("Example", 250, 50)

	local $some_other_control = GUICtrlCreateCheckBox("a checkbox..", 115, 10)
	local $some_input = GUICtrlCreateInput("text here", 10, 10, 200)

    ; Display the GUI.
    GUISetState(@SW_SHOW, $hGUI)

    while 1

		$mouse_pos = GUIGetCursorInfo ($hGUI)
		if IsArray($mouse_pos) and $mouse_pos[4] = $some_input then
			ControlMove ($hGUI, "Example", $some_input, default, default, 200)
		else
			ControlMove ($hGUI, "Example", $some_input, default, default, 100)
		endif


        switch GUIGetMsg()
            Case $GUI_EVENT_CLOSE
                exitloop

        endswitch
    wend

    GUIDelete($hGUI)
endfunc

[Melba23]

When I run this script on my Win7 machine I see the behaviour you describe under Win 8 - the underlying control becomes visible when the cursor moves over it even though the input is extended. So I do not see this as a bug as described (change from Win 7 to Win 8).

Anyway there is a simple workaround to create what is claimed to be the "old" behaviour - just hide the other control when the input is extended:

#include <GUIConstantsEx.au3>

Example()

Func Example()

	Static Local $bVisible = True

	Local $hGUI = GUICreate("Example", 250, 50)

	Local $some_other_control = GUICtrlCreateCheckbox("a checkbox..", 115, 10)
	Local $some_input = GUICtrlCreateInput("text here", 10, 10, 200)

	GUISetState(@SW_SHOW, $hGUI)

	While 1

		$mouse_pos = GUIGetCursorInfo($hGUI)
		If IsArray($mouse_pos) And $mouse_pos[4] = $some_input Then
			ControlMove($hGUI, "Example", $some_input, Default, Default, 200)
			If $bVisible Then
				GUICtrlSetState($some_other_control, $GUI_HIDE)
				$bVisible = False
			EndIf
		Else
			ControlMove($hGUI, "Example", $some_input, Default, Default, 100)
			If Not $bVisible Then
				GUICtrlSetState($some_other_control, $GUI_SHOW)
				$bVisible = True
			EndIf
		EndIf

		Switch GUIGetMsg()
			Case $GUI_EVENT_CLOSE
				ExitLoop

		EndSwitch
	WEnd

	GUIDelete($hGUI)
EndFunc   ;==>Example

Could I ask that next time you post in the forum to confirm that others can reproduce what you consider to be a bug before raising a ticket.

M23

[anonymous]

If it wasn't a bug, there would be no need for a "workaround". How could behaviour changing from one OS to the next be anything but a bug? Anyone with access to both OS could verify this. But hey, if you don't want to fix it, no problem.

[Melba23]

But the behaviour you describe as "wrong" under Win 8 is exactly what I see under Win 7 - so there is no change of behaviour with change of OS and so nothing to fix. Just to be clear, the "workaround" was just some code to get the behaviour you say is "normal" - but which for me was not. It was not an admission that this behaviour was expected.

I have no idea what caused your Win 7 behaviour to be "different" but, as I mentioned above, if you had asked in the forum first you get a wider audience to confirm a bug before raising a ticket.

M23