gui button looses default status after reactivating Topic is solved

Report problems with documented functionality
Rollo007
Posts: 17
Joined: 24 Mar 2021, 08:23

gui button looses default status after reactivating

27 Apr 2021, 13:47

With the option "Default" you can determine whether a button should have the default status. However: If the window loses focus, the first button in the window receives the default status when it is activated again, even if another button only has this option.
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: gui button looses default status after reactivating

28 Apr 2021, 03:09

It is standard dialog behaviour for a button to become the "default" while it is focused, so that pressing Enter activates the focused button, not the original default button. Since you have not provided any code demonstrating the issue, I am going to assume that the button is merely being focused, and not actually becoming the default. If you focus another non-button control, you will see that the original button is still the real default.
Rollo007
Posts: 17
Joined: 24 Mar 2021, 08:23

Re: gui button looses default status after reactivating

28 Apr 2021, 08:27

lexikos wrote:
28 Apr 2021, 03:09
It is standard dialog behaviour for a button to become the "default" while it is focused, so that pressing Enter activates the focused button, not the original default button. Since you have not provided any code demonstrating the issue, I am going to assume that the button is merely being focused, and not actually becoming the default. If you focus another non-button control, you will see that the original button is still the real default.
No, this is definitifly not the standard dialog behaviour.
Show a MsgBox like
msgbox 0x103, t,ttt
The 2nd button is default and even if you change the window-focus (for example with [Alt]+[Tab]) to another window and then get back to the MsgBox (same way), - the 2nd butten STILL has the focus / default status.
This is standard.
bsp2.jpg
bsp2.jpg (22.46 KiB) Viewed 1164 times
But a gui window makes something irregular.
The "default" option is lightening a button and capture an Enter on it BUT it does not take the keyboard focus as it should (even if it could be set with 'guicontrol focus").
You can see that inconsistency status as the first button has that dotted outline and the 2nd has highlighting. This should only be different between different classes. For example an edit and a button.
As the keyboard focus stays (unchangeable) on the first button it will get the default-option (highlighting) too after reactivation (getting back focus) and this is even not changable with an WM_ACTIVATE capture that rechange default status.
bsp2.jpg
bsp2.jpg (22.46 KiB) Viewed 1164 times
Finally:
"Default" should bring the
- highlighting
- [Enter]-captureing
- keyboard focus (dotted outline)
- mouse-position (if the option 'go to default button' is on)

as it do it on MsgBox but not on Gui.


Gui-Example:

Code: Select all

Gui, HauptF:New , +HwndGuiHwnd, Installation
HauptfensterHwnd:= GuiHwnd

Gui, Font, s12
Gui, Add, Text,, 		Topic
Gui, Font, s9
Gui, Add, Text,, 		Blabla
;Gui, Add, Button,		gLizenzTasteClick vLizenzTaste, Taste1
Gui, Add, Text,,     
Gui, Add, Text,, 		blablablablablablablablabla
;Gui, Add, Button,		gReadMeTasteClick  vReadMeTaste, ReadMe
Gui, Add, Text,,     

Gui, Add, Button, 	gGoOnTasteClick vGoOnTaste, Go on
Gui, Add, Button, 	gCancelTasteClick x+10 default w100, Cancel
Gui, Add, Button, 	gWeitereOptionenClick x+10, Options

Gui, Show
[Mod edit: [code][/code] tags added.]


**Don't know why the pics appears twice
Attachments
bsp1.jpg
bsp1.jpg (10.62 KiB) Viewed 1164 times
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: gui button looses default status after reactivating

28 Apr 2021, 22:04

Rollo007 wrote:
28 Apr 2021, 08:27
lexikos wrote:
28 Apr 2021, 03:09
It is standard dialog behaviour for a button to become the "default" while it is focused, [...]
No, this is definitifly not the standard dialog behaviour.
What do you mean "no"? I described the standard behaviour, which is different to what you are seeing.

Your MsgBox screenshots show that the focused button is the default button. This is consistent with what I said, but proves nothing.

Your GUI screenshot clearly shows that the first button is focused and the second button is the default. Default status is indicated by the blue highlight. When you say that the first button has the default status, you are using the wrong terminology.
Rollo007
Posts: 17
Joined: 24 Mar 2021, 08:23

Re: gui button looses default status after reactivating

01 May 2021, 06:07

Sorry Steve, English is not my mother language and maybe I misunderstood you.
I try to bring it to a point.
Usually, if a button is set to default, it automatically gets the keyboard focus (is focused).
This is working korrekt on the MsgBox or InputBox.
But it is not working on Gui buttons. There, if you set a button to default, the focus remain to the button/control it was.
I know that it is necessary to part default and focus, but only between different classes of control elements.
Within the same class, both should get together and I think setting the default status should set the focus too (at least if the control which had the default/focus before is the same class).

Hope I have described better now.
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: gui button looses default status after reactivating

01 May 2021, 22:59

Usually, if a button is set to default, it automatically gets the keyboard focus (is focused).
Not true. A button is virtually always set as default when the dialog is created, before the dialog is focused. The default button often changes in response to the focus changing, but the reverse never happens. There is no way for a user to directly initiate a change of default button; the user can only switch the focus.

The focus has to be placed somewhere when the window initially gains focus, and it might make sense to choose the default button for that, which I think is what you're really asking for. However, that generally only happens on MsgBox and similar dialogs that only have buttons. For instance, "Find", "Open", "Save", "Run", "Print", "Font", InputBox ... all these have an input field focused by default, and a separate default button which does not initially have the focus.

Placing initial focus on the default button would not necessarily be the intent of the author, and even if it were desired, changing Gui to do so might break some scripts. If you want the default button to also be focused by default, then you must focus it after showing the GUI.

I think the standard behaviour when a GUI is shown is for the first control to be focused, and this is implemented by the system, not specifically by AutoHotkey. However, if the first control is a Button, it would make sense to instead focus the Default button. Currently, as shown in your screenshot, the GUI starts in an inconsistent state where the first button has focus but isn't the default. I will consider changing the behaviour for v2, but probably not v1.
Rollo007
Posts: 17
Joined: 24 Mar 2021, 08:23

Re: gui button looses default status after reactivating

03 May 2021, 12:43

lexikos wrote:
01 May 2021, 22:59
The focus has to be placed somewhere when the window initially gains focus, and it might make sense to choose the default button for that, which I think is what you're really asking for.
That's right.

I understand your arguments. In fact, this example I showed you (with the inconsistent status) is been corrected automatically if the window looses the focus and get it again. Then the default status has changed to the first button by itself. And this is a little bit weird.

Of course I have solved this like you wrote but at first I was confused of this behavior and maybe a hint in the help would be good idea, if you do not decide to change this.


By the way, I have another question:
Please look at this small example...

Code: Select all

Test:= "Test1`rTest2`r"
loop Parse, Test, `r
	msgBox % A_LoopField
Why do it 3 loops? Or with other words: Why do it a 3rd loop with an empty A_Loopfield?
Okay, it is not a bug, cause you take the "`r" in that example as an Separator. BUT is this helpfully? Are there not much more cases like it is in my example and it makes an additional programming work to catch this.
I know you make a good job to simplify the skripting. I think it would be more easy if the loop do not make a run with an empty Loopfield. At least I don't know what kind of gain that could have.

Best regards
Roland
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: gui button looses default status after reactivating  Topic is solved

05 May 2021, 05:42

Actually, the current behaviour is documented:
When the window is shown for the first time, the first input-capable control that has the Tabstop style (which most control types have by default) will have keyboard focus.
I also realized that someone might use the current behaviour as a way to have an easy shortcut for the first button (Space) and the default button (Enter), so I will not change this in v1.

However, I will change it in v2 because focusing the default button (if the first input-capable control is a button) seems more intuitive, and so that the initial state is consistent with how it is after the window or control loses and regains focus.
Rollo007
Posts: 17
Joined: 24 Mar 2021, 08:23

Re: gui button looses default status after reactivating

13 May 2021, 12:53

Okay, - I had waited a bit if you say something to the other topic, but it seems you don't want to.
Anyway, I do have some suggestions and maybe bugs. Should we write about right here or do you want me to open a new thread for each?

Kind Regards
Roland
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: gui button looses default status after reactivating

14 May 2021, 03:25

Rollo007, I assume you are addressing me, but I'm not sure what other topic you are referring to, or why I would be expected to say something more in it.

If your suggestions directly relate to the specific issue described in this thread, post them here. Otherwise, don't.

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 20 guests