Focus on a default button

[renArD]

Hi,
I'm pretty sure this may have already been asked somewhere but I miss good search keywords. That's why I dare to ask.
I would like to understand different behaviours. Here is the code :

Code: Select all

SimpleWindow()
return

~^c::SimpleWindow()
return

SimpleWindow()
{
	Gui, Add, Button, Default, ok
	;GuiControl,Focus, ok
	Gui, Show
	return
}

If I run the program, the gui loads like that :

image.png (1.4 KiB) Viewed 1086 times

But if I (close the previous window, click somewhere and) run the hotkey, the gui loads like that :

image.png (1.43 KiB) Viewed 1086 times

But if I run the program, close the gui and then run hotkey (without clicking anywhere in between the actions) it loads like that :

image.png (1.43 KiB) Viewed 1086 times

If I remove "Default", the behaviour when running autoexecute part is different (the button without selection, which is normal) but the hotkey ran gui looks like just above (with or without clicks somewhere).
Doing more hotkey calls shows that it's sometimes one behaviour, sometimes the other. I'm lost...

Why such differences ? How to force a behaviour among others ?

The commented line seems not to change anything.

Thanks

[mikeyww]

Adding a control to a GUI does not first destroy the GUI if it already exists. It simply adds another control and leaves the others intact. Only one button can be the default button.

Code: Select all

#Requires AutoHotkey v1.1.33
^c::
; Gui Destroy
Gui Add, Button, w230 Default, OK
Gui Show, AutoSize
WinGet list, ControlList, ahk_class AutoHotkeyGUI
ToolTip % list
Return

[renArD]

Thank you very much for this relevant and interesting information! Autosize is a good way to realize what is really built, and you made me realize the need to Destroy.
However, I'm still surprised by many things.
First of all, the ControlList always give the same result :

Static1
Button1
Edit1
Static2
Edit2
Static3
Edit3
Static4
Edit4
Static5
Edit5
Button2
Static6
Edit6
Static7
Edit7
Static8

It includes many things I don't understand, but if I count Buttons, I see there are two of them. Ok, let's say it's something I don't understand and there might always be an hidden "Button2" (SpyWindow said me the "ok" button was Button1). But why this ControlList is always the same, even when I load multiple times the hotkey (many buttons appears since I didn't uncomment Gui Destroy) ? Even if I remove the "Add Button" line (so that there is no button), the list remains the same!

Second interrogation :
Thanks to your code, one of the three previous behaviours is gone. But I still have two different behaviours. Please let me remind the code, with your inputs :

Code: Select all

SimpleWindow()
return

SimpleWindow()
{
	Gui, Destroy
	Gui, Add, Button, w230 Default, OK
	Gui, Show, AutoSize
	WinGet list, ControlList, ahk_class AutoHotkeyGUI
	ToolTip % list
	return
}

~^c::SimpleWindow()
return

At startup it gives :

image.png (2.57 KiB) Viewed 1006 times

And with hotkey it gives :

image.png (2.73 KiB) Viewed 1006 times

Why is it different?

[mikeyww]

It appears that the script that you posted is not the script that you are running. Different scripts may yield different results. When I tried your script, I saw nothing unusual. When you destroy the GUI, a new GUI would then be rebuilt and so would have the same controls each time.

[renArD]

Thanks for taking time on this case.
I'm surprised by your answer. So I cleaned up everything, put only what I wrote in my previous post, and the look is the same. But for the Tooltip answer, it's true it's been cleaned up (I see only Button1). Sorry for that.
(btw I'm still surprised because when I revert back to my previous file (with some old tests remaining), I couldn't reproduce what I said in the previous post : I only see Button1...)

I attach the file to get deeper in the "look" question

test.ahk

test file with mentioned lines

(229 Bytes) Downloaded 17 times

On the first load (initial startup), if I hit Tab and then Space, then I have the second look.

[mikeyww]

I am not sure what you are seeing, but I am not seeing anything strange or problematic with your newest script.

Output

image230316-0941-001_cr.png (7.26 KiB) Viewed 955 times

[renArD]

Thanks
Do you see this on first load or with hotkey? I only have this (ie. dashed lines) with hotkey!

[mikeyww]

No changes-- same with both.

I wonder if you are running multiple scripts, different scripts, did not save your script, etc. You should close all scripts before you test.

[renArD]

I'm sorry that you have to remind such basic stuff but I did close all other scripts (and save the file!). I rebooted computer (even in safe mode) and it's the same.

I tried in v2 (probably with mistakes because it's my first steps !) and it's the same :

Code: Select all

#Requires AutoHotkey v2.0

SimpleWindow()
return

SimpleWindow()
{
	static MyGui
	if IsSet(MyGui)
		MyGui.Destroy()
	MyGui := Gui()
	MyGui.Add("Button","w230 Default", "OK")
	MyGui.Show("AutoSize")
	return
}

~^c::SimpleWindow()

When trying, I had one time or two the hotkey call without the dashed lines. But it's not reproducible...

[mikeyww]

OK.

I am not reproducing your issue. If you are running some other process that also handles the clipboard, it could be stealing the window focus.

Others may have more to say about your problem.

[renArD]

Thanks for all your help until now. I hope someone will have an idea.

[off]

The dash line around button, ah yeah, its happened if user focusing a control, with click, pressing tab, arrow keys, or even hovering sometimes..

Maybe using GuiControl, Focus?

[renArD]

Hi, thanks for your reply !
The dashed lines I'm referring to are these.
As stated in the original post, "GuiControl,Focus, OK" doesn't change the behaviour.
I also tried "ControlFocus,OK,mywindow" but no change.

Said differently, in the code bellow, the commented lines doesn't change the look because the button has always the focus (confirmed by the Tooltip which returns "Button1").

Code: Select all

#Requires AutoHotkey v1.1.33
SimpleWindow()
return

SimpleWindow()
{
	static Variable
	Gui, Destroy
	Gui, Add, Button, w230 Default vVariable, OK
	Gui, Show, AutoSize, mywindow
	;GuiControl,Focus, OK
	;ControlFocus,OK,mywindow
	GuiControlGet, focused_control, Focus
	ToolTip %focused_control%
	return
}

~^c::SimpleWindow()

But having the Focus seems not to mean having the dashed lines. So the look/behaviour remains different between the first run (autoexecute part) and the hotkey.

[off]

Hello, i just using my computer today and managed to create this,
Using a hidden button, and getting "Dashed-Focused-Control-Indicator" to the hidden button, and making another button as default, it completely remove the dashed line, even after using the function again. But pressing tab will show the dash line again. I hope this what you looking for.

Code: Select all

#Requires AutoHotkey v1.1.33
SimpleWindow()
return

SimpleWindow()
{
	static Variable
	Gui, Destroy
	Gui, Add, Button, w230 Default, OK
	Gui, Add, Button, w0 h0 x-100 y-100, Placeholder
	Gui, Show, AutoSize, mywindow
	GuiControl, Hide, Button2
	GuiControl,Focus, Button2
	;ControlFocus,Button1,mywindow
	GuiControlGet, focused_control, Focus
	ToolTip %focused_control%
	return
}

~^c::SimpleWindow()

[renArD]

Thank you very much for your answer.
You're right to say that Tab can make the dashed lines appear. However I hoped to find a way not to use such tricks.
Doing other tests, I realize that the title of this thread isn't correct. It seems that the matter (dashed lines) isn't equivalent to Focus (because there can be the focus without the dashed lines). And it seems it isn't about 'Default' either because dashed lines can appear on a non-Default button too (below the gui when removing the "Default" option) :

image.png (2.69 KiB) Viewed 845 times

To summarize the questions I would say:
- what's the real technical name of "having dashed lines" so that I can search further ? It seems it's not (only) about Focus
- how to force to have or not to have the dashed lines, without tricks ?

[off]

Did you test my script?
Is it removing the line when you start and using the hotkey?

[renArD]

Sorry I didn't answer enough!
The trick you propose is a way not to have the dashed lines (first run and hotkey) but unfortunately the focus is lost (pressing space bar doesn't "push" the button)

[off]

After some researching, this seems the closer what you need
viewtopic.php?t=9919

Or maybe just

Code: Select all

#Requires AutoHotkey v1.1.33
SimpleWindow()
return

SimpleWindow()
{
	static DefaultBtn
	Gui, Destroy
	Gui, Add, Button, gDefaultBtn vDefaultBtn w230 Default, OK
	Gui, Add, Button, gDefaultBtn w0 h0 x-100 y-100, Placeholder ; same gDefaultBtn, when pressing spacebar, since default button just have visual "focused"
	Gui, Show, AutoSize, mywindow
	GuiControl, Hide, Button2
	GuiControl, Focus, Button2
	;ControlFocus,Button1,mywindow
	;GuiControlGet, focused_control, Focus
	;ToolTip %focused_control%
	return
}

~^+c::SimpleWindow()

DefaultBtn: ; executed when using spacebar
MsgBox, Focused
SimpleWindow() ; destroying and rebuilt the GUI
Return

[renArD]

Thank you very much for this interesting input. The link provided speaks about a function "HideFocusBorder" which didn't work for me. But it gave clues to go deeper in understanding WM_UPDATEUISTATE
I found this interesting article : https://devblogs.microsoft.com/oldnewthing/20130517-00/?p=4323 which made me realize that the dots reveal what was the last input : mouse or keyboard.
- If I (re)load my program, it's by mouse, so I don't have the dots
- If I run hotkey, it's by keyboard, so I have the dots.
To confirm, I ran the program by keyboard (hit enter on windows explorer) and I got the dots. And I reran the function by mouse (I said it is the action for OK button) and I lost dots.
Now I have to look how to be sure to have (or not) dots, whatever action built the Gui.

I shorten my message which initialy explained many discovery steps. I tried many things with

Code: Select all

MAKEWPARAM(l, h)
{
	return (l & 0xffff) | (h & 0xffff) << 16
}
WM_UPDATEUISTATE := 0x0128
UIS_SET          := 1
UIS_CLEAR		:= 2
UIS_INITIALIZE	:= 3
UISF_HIDEFOCUS   := 0x1
UISF_HIDEACCEL	:= 0x2
UISF_ACTIVE		:= 0x4
PostMessage WM_UPDATEUISTATE, MAKEWPARAM(UIS...,UISF...), 0,, "ahk_id " MyGui.Hwnd

I changed "UIS..." and "UISF..." with values declared above and noticed different behaviours when loading the program (by mouse or keyboard, as explained above) and when doing action like mouseover, tab key, alt key, mouseover after those keys etc.

So I wanted to get rid of different behaviours. Two ways : to have or not to have dots every time, even with Tab or mouseover. I made many test/combinations (and got very helped with this great article : https://devblogs.microsoft.com/oldnewthing/20171124-00/?p=97456 ). Finally :
- To have dots all the time, a simple way is to check "Underline keyboard shortcuts and access keys" in window's keyboard parameters. But it's not set by the program so it depends where the program will be ran. The various tests reavealed (something maybe obvious for experts) that the UIstate had to be 0. So I thought I just had to run (without the lines mentionned above) :

Code: Select all

PostMessage WM_UPDATEUISTATE, MAKEWPARAM(UIS_CLEAR,UISF_HIDEFOCUS&UISF_HIDEACCEL&UISF_ACTIVE), 0,, "ahk_id " MyGui.Hwnd ;UISF_HIDEFOCUS&UISF_HIDEACCEL&UISF_ACTIVE is 7

But no, it doesn't do the trick. However, If I do this two lines it's ok ("ok" just means it works, not that UIstate is 0) :

Code: Select all

	PostMessage WM_UPDATEUISTATE, MAKEWPARAM(UIS_CLEAR,UISF_HIDEFOCUS), 0,, "ahk_id " MyGui.Hwnd ;see remark bellow
	PostMessage WM_UPDATEUISTATE, MAKEWPARAM(UIS_CLEAR,UISF_HIDEACCEL), 0,, "ahk_id " MyGui.Hwnd

Remark : I also noticed that the first line above (with UISF_HIDEFOCUS) isn't needed if the button hasn't been defined with the "Default" option.

- To remove dots all the time, if the button isn't "Default", then this lines seems to be enough:

Code: Select all

	PostMessage WM_UPDATEUISTATE, MAKEWPARAM(UIS_SET,UISF_HIDEFOCUS), 0,, "ahk_id " MyGui.Hwnd
	PostMessage WM_UPDATEUISTATE, MAKEWPARAM(UIS_SET,UISF_HIDEACCEL), 0,, "ahk_id " MyGui.Hwnd

There is no dots until mouseover of tab or Alt. Ok I shouldn't say dots are removed "all the time", but the behaviour is the same with clicks and keyboard.
If you want the (first) mouseover not to make dots appear, add

Code: Select all

PostMessage WM_UPDATEUISTATE, MAKEWPARAM(UIS_SET,UISF_ACTIVE), 0,, "ahk_id " MyGui.Hwnd

But after Tab the mouseover will react and put dots.
If the button has the Default option, I've no solution to remove dots so far.

I hope I've been clear since I drowned myself in all my tests!
Thanks again, off and mikeyww for your precious help. I hope this post will help someone.