#2935 closed Bug (No Bug)
GUIGetCursorInfo behavior in Windows 8
Reported by: | corz | Owned by: | |
---|---|---|---|
Milestone: | Component: | AutoIt | |
Version: | 3.3.13.19 | Severity: | None |
Keywords: | Cc: |
Description ¶
; 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
Change History (3)
comment:1 Changed 10 years ago by Melba23
- Resolution set to No Bug
- Status changed from new to closed
comment:2 Changed 10 years ago by 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.
comment:3 Changed 10 years ago by 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
Guidelines for posting comments:
- You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
- In-depth discussions should take place on the forum.
For more information see the full version of the ticket guidelines here.
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:
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