Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

Discuss the future of the AutoHotkey language
User avatar
Flipeador
Posts: 1018
Joined: 15 Nov 2014, 21:31
GitHub: Flipeador
Location: Argentina
Contact:

Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

15 Jul 2018, 13:17

Gui.FocusedCtrl: Currently retrieves the GuiControl object of the GUI's focused control. But in a ComboBoxEx control the control that takes the focus is the Edit control. I propose to add FocusedCtrlHwnd or that FocusedCtrl return HWND if the control that has the focus was not created by the Add method of the GUI object.

Code: Select all

Gui := GuiCreate()
Gui.AddCustom("ClassComboBoxEx32 +0x40 +0x2")
Gui.AddComboBox()
Gui.Show()
Gui.OnEvent("Close", "ExitApp")
Return

F1::
ToolTip Type(Gui.FocusedCtrl)
Return

ControlGetFocus: I propose that this function returns the control's identifier instead of the ClassNN. Because the identifier is more useful. Or we can add ControlGetFocusHwnd.


Gui Controls: I would like to know if you intend to improve the methods of the Gui Controls. Currently the methods are of "general scope", very poor. Because of this I have to use a class wrapper. Yes, I know, I can make my own functions, but I would be losing the "comfort" of using the Gui Control Object. As an example, see my class Tab, there is an important method to calculate the display area to know where to put controls, as well as the possibility of adding icons. I know that if you omit the X and Y coordinates, the control automatically adjusts, but, what if we want a different margin? What about the height and width?. This I can apply to almost all controls, its implementation is very poor.
I would also like to remove the ComboBox control and replace it with ComboBoxEx. Also see my class, I think it is the most appropriate behavior (see the Focused property).
I also want to ask about behavior that I do not understand in my class. If you change the Text parameter to ByRef in the FindString method, then when you use it with #Warn it gives you a warning, I do not know why.
Windws 1♂ Pro 64-Bits I make scripts for AHKv2 (my v2 compiler) & WIN_7+ Spanish Argentina SublimeText 3 & AHKv2 My GDI+ Library
User avatar
jeeswg
Posts: 5152
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

18 Jul 2018, 20:18

- I like the ControlGetFocusHwnd idea. It's mentioned on my Wish List 2.0.

Code: Select all

vCtlClassNN := ControlGetFocus("A")
hCtl := ControlGetHwnd(vCtlClassNN, "A")

hCtl := ControlGetFocusHwnd("A")
- Assuming that no built-in support was added for further controls, is there any general functionality you would like to see added to facilitate supporting custom controls?
Last edited by jeeswg on 18 Jul 2018, 22:07, edited 1 time in total.
User avatar
Flipeador
Posts: 1018
Joined: 15 Nov 2014, 21:31
GitHub: Flipeador
Location: Argentina
Contact:

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

18 Jul 2018, 20:46

I like the ControlGetFocusHwnd idea
It seems to be the best option.
Edit* I did not read your comment well, I thought it referred to Gui.FocusedCtrlHwnd. The truth is I am against ClassNN... I prefer that the ControlGetFocus function returns an identifier. For the reason I mentioned above. It is more useful.
Assuming that no built-in support was added for further controls, is there any general functionality you would like to see added to facilitate supporting custom controls?
I'm not sure what you mean. I'm not interested in custom controls.
I am proposing to dedicate a separate section for each control, where their own methods are described. As an example, it has the ListView control. Of course, this only makes sense if, as I propose, more methods are added. When you are going to make a minimally decent user interface, the current implementation is not good. You have to resort to functions, and you lose the comfort of using the built-in class object.
Regarding the ComboBox control, I propose to replace it with ComboBoxEx.
Windws 1♂ Pro 64-Bits I make scripts for AHKv2 (my v2 compiler) & WIN_7+ Spanish Argentina SublimeText 3 & AHKv2 My GDI+ Library
User avatar
jeeswg
Posts: 5152
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

18 Jul 2018, 21:17

- There's a distinction:
- (1) Built-in support for control type X because it's convenient.
- (2) Built-in support for control type X because key functionality is currently impossible with the generic custom control support.
- Although I would welcome built-in support simply for convenience, improving the support for custom controls in general, would be my priority. And I would be interested in any suggestions you might have, since presumably you've experienced problems using ComboBoxEx controls alongside the built-in GUI functionality.
User avatar
Flipeador
Posts: 1018
Joined: 15 Nov 2014, 21:31
GitHub: Flipeador
Location: Argentina
Contact:

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

18 Jul 2018, 21:54

presumably you've experienced problems using ComboBoxEx controls alongside the built-in GUI functionality
The only problem I'm having is in Gui.FocusedCtrl. It's useless with ComboBoxEx controls. I still do not understand what you mean :lol:.
There's a distinction [...]
I am proposing to add more methods to the controls in general, and modify the current behavior in some others. :!: :?:
Note: I edited my comment above, I misunderstood you.
Windws 1♂ Pro 64-Bits I make scripts for AHKv2 (my v2 compiler) & WIN_7+ Spanish Argentina SublimeText 3 & AHKv2 My GDI+ Library
User avatar
jeeswg
Posts: 5152
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

18 Jul 2018, 22:13

- Here is the documentation for custom controls:
GUI Control Types
https://lexikos.github.io/v2/docs/comma ... htm#Custom
- Are there more things that need considering in your view?
- Presumably you would prefer ComboBoxEx to be built-in, but let's say it wasn't. What generic functionality, applicable to all built-in/custom control types might be useful to facilitate using ComboBoxEx (or another control type) as a custom control.
- Also, are there any other custom control types that you use regularly?
User avatar
Flipeador
Posts: 1018
Joined: 15 Nov 2014, 21:31
GitHub: Flipeador
Location: Argentina
Contact:

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

19 Jul 2018, 08:43

What generic functionality, applicable to all built-in/custom control types might be useful to facilitate using ComboBoxEx (or another control type) as a custom control
I do not know, this is not what is being discussed here. I'm not interested in any generic behavior for all Custom controls. Here we are discussing the current behavior of the built-in functionality. I'm not interested in adding the ComboBoxEx control (as a new one). If the ComboBox control is replaced by ComboBoxEx, Gui.FocusedCtrlHwnd would not make sense, since we can adapt Gui.FocusedCtrl for a special handling with ComboBoxEx controls. ComboBoxEx_Gui_CtrlObj.Focused would return 1 if the edit control has the focus, 2 if the ComboBox has it (the drop-down list is shown) and 0 if it does not have the focus (as it is in my class).
Also, are there any other custom control types that you use regularly?
I do not know what this has to do with this topic, but not at the moment. I proposed to add the Toolbar control in another topic. :?
Windws 1♂ Pro 64-Bits I make scripts for AHKv2 (my v2 compiler) & WIN_7+ Spanish Argentina SublimeText 3 & AHKv2 My GDI+ Library
User avatar
jeeswg
Posts: 5152
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

04 Sep 2018, 19:39

- Instead of 'ControlGetFocusHwnd', perhaps these could return the hWnd of the focused control:

Code: Select all

hCtl := ControlGetHwnd(, "A")
hCtl := ControlGetHwnd("", "A")
- I'm surprised that they don't already, instead they give the 'topmost control', which is the first control found by WinGetControls (WinGet-ControlList).
- I can't see how the topmost control would ever be useful for any ControlXXX function, AFAIK I've never needed/wanted it, so I'd welcome anyone to argue for the topmost control over the focused control. Cheers.

- (I'd welcome ComboBoxEx/ToolbarWindow32 being introduced, but not necessarily for the 1st AHK v2 release. And I would keep ComboBox.)
- (My priority would be to consider any slight improvements to facilitate using custom controls.)
User avatar
Flipeador
Posts: 1018
Joined: 15 Nov 2014, 21:31
GitHub: Flipeador
Location: Argentina
Contact:

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

04 Sep 2018, 23:10

Instead of 'ControlGetFocusHwnd', perhaps these could return the hWnd of the focused control
Actually I prefer that the "main version" (ControlGetFocus) return the identifier of the control.
(I'd welcome ComboBoxEx/ToolbarWindow32 being introduced, but not necessarily for the 1st AHK v2 release. And I would keep ComboBox.)
I think we should not continue adding controls if we do not plan to improve the current ones before, as I mentioned, there are many methods that could be added and that are very useful, the current implementation leaves much to be desired.
For example, if we add the Toolbar control (with missing methods, like all the others), I will probably end up using my class.
(My priority would be to consider any slight improvements to facilitate using custom controls.)
I think you should create another topic.
Windws 1♂ Pro 64-Bits I make scripts for AHKv2 (my v2 compiler) & WIN_7+ Spanish Argentina SublimeText 3 & AHKv2 My GDI+ Library
lexikos
Posts: 6176
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

05 Sep 2018, 17:03

Flipeador wrote:Gui.FocusedCtrl: Currently retrieves the GuiControl object of the GUI's focused control. But in a ComboBoxEx control the control that takes the focus is the Edit control.
Edit takes the focus for ComboBox as well. The difference between ComboBox and ComboBoxEx is an extra level of indirection: the ComboBoxEx has a ComboBox as a child, which has an Edit as a child. FocusedCtrl only calls GetParent once, so it does not find the main control window.

In the context of the Gui object, which is not intended to mirror Win32 like the Win and Control functions, the ComboBoxEx32 is a single control composed of multiple Win32 windows. Edit is not a control of its own, and therefore not the focused control. It can be compared to controls like MonthCal, which has multiple fields that can be focused within the control.

I would consider adding FocusedHwnd, which does not imply that the HWND belongs to a control.
ControlGetFocus: I propose that this function returns the control's identifier instead of the ClassNN. Because the identifier is more useful.
Is it? The ClassNN of controls in a window are often known in advance. Comparison of the ClassNN is convenient and readable, and the ClassNN can also be used to identify the control. Comparison of the HWND to determine if a control external to the script is active would often be impossible.

But if we implement this...

Code: Select all

HWND := ControlActive(Control [, WinTitle ...])
...there is one less reason to want the ClassNN of the focused control. One can pass a ClassNN or caption text to determine if a control is focused. If one uses caption text to retrieve the HWND of the control for comparison, there is a risk that the comparison will get the wrong result because the caption text is ambiguous. ControlActive() would not have this issue because it would only check the focused control.

There is still another important reason to have the ClassNN: debugging. Displaying the HWND is next to useless for debugging. Allowing ControlGetClassNN(ControlGetFocus()) provides some consolation (ControlGetClassNN should have been added long ago). The existing functions need some work before they can detect a HWND by type (integer).

I suggest to avoid using the term "identifier" unless you mean it generically. Both the ClassNN and HWND of the control are identifiers. Even text is an identifier, though not always unique.
I would like to know if you intend to improve the methods of the Gui Controls.
I lack any interest in working on the GUI. Unless there is a specific need to do so for the completion of v2.0, I do not anticipate "improving the methods of the Gui Controls".
Currently the methods are of "general scope", very poor.
I do not know what you mean.
As an example, see my class Tab, there is an important method to calculate the display area to know where to put controls,
Why do you not utilize the built-in automatic placement of controls?
as well as the possibility of adding icons.
I would consider this a frivolous feature. Icons are rarely used in tabs within Windows.
what if we want a different margin?
Assign a different margin before/after adding a control. I don't see the problem.
What about the height and width?
What about it? I don't see what you're getting at.


For custom controls and customization of standard controls, I imagine that one will eventually be able to monkey-patch or extend the built-in control classes. The class (object) of control might be passed instead of a name (string). However, I do not plan to make this part of the initial v2.0 release.
User avatar
nnnik
Posts: 3358
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

06 Sep 2018, 01:29

For custom controls and customization of standard controls, I imagine that one will eventually be able to monkey-patch or extend the built-in control classes. The class (object) of control might be passed instead of a name (string). However, I do not plan to make this part of the initial v2.0 release.
Would you mind if someone else made that a PR?
Recommends AHK Studio
User avatar
jeeswg
Posts: 5152
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

06 Sep 2018, 01:33

@nnnik: Here's a bit of AHK code as a template just in case it saves you some time.

Code: Select all

;==================================================

JEE_CtlGetClassNN(hCtl)
{
	;WinGetClass, vWinClass, % "ahk_id " hCtl
	vWinClass := WinGetClass("ahk_id " hCtl)
	hWnd := DllCall("user32\GetAncestor", Ptr,hCtl, UInt,1, Ptr) ;GA_PARENT := 1
	Loop
	{
		;ControlGet, hCtl2, Hwnd,, % vWinClass A_Index, % "ahk_id " hWnd
		hCtl2 := ControlGetHwnd(vWinClass A_Index, "ahk_id " hWnd)
		if !hCtl2
			break
		else if (hCtl = hCtl2)
			return vWinClass A_Index
	}
}

;==================================================

;e.g. hCtl := JEE_ControlGetFocusHwnd("A")

JEE_ControlGetFocusHwnd(vWinTitle:="", vWinText:="", vExcludeTitle:="", vExcludeText:="")
{
	hWnd := WinActive(vWinTitle, vWinText, vExcludeTitle, vExcludeText)
	vCtlClassNN := ControlGetFocus("ahk_id " hWnd)
	return ControlGetHwnd(vCtlClassNN, "ahk_id " hWnd)
}

;==================================================
User avatar
nnnik
Posts: 3358
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

06 Sep 2018, 02:30

I clarified what my comment refered to.
Recommends AHK Studio
lexikos
Posts: 6176
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

06 Sep 2018, 03:34

nnnik wrote:Would you mind if someone else made that a PR?
What are you asking? Would I reject a pull request that satisfies my requirements? Or do I want to implement it myself? (Even though "I lack any interest in working on the GUI.")

If you or anyone else wants to make an attempt at implementing any of the things that I've indicated will be part of v2.0, I am happy to review the pull request. Anything I have indicated I want to implement but isn't planned for v2.0 is also fair game. If someone submits a pull request for something they want that I've never heard of, that's fine too. However, I won't promise to merge anything before I see it.
lexikos
Posts: 6176
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

09 Sep 2018, 06:16

I realized something about ControlGetFocus: if it returns a HWND, all of the parameters are redundant.

Within a given session, there is only one focused control (actually, window), and it resides on the active window, or is the active window itself. For the script's own thread, DllCall("GetFocus", "ptr") returns its HWND. ControlGetFocus finds the specified window, retrieves its thread ID and then uses GetGUIThreadInfo to retrieve the focused HWND of that thread (not window).

Since a ClassNN contains the control's sequence number within the target window, it must exist within that window. If some control belonging to the same thread as the target window has focus but it has a different parent, ControlGetFocus receives its HWND but the ClassNN calculation yields a blank result. This is how the following effect is achieved:
If [...] none of the target window's controls has focus, the return value is blank.
So the question is: when we query the focused control with ControlGetFocus(), do we most often want an answer only if it belongs to a specific window, or do we usually call ControlGetFocus("A")? If it's the latter, perhaps ControlGetFocus() should have no parameters and just return the HWND of the focused control within the active window. Otherwise, to return the HWND only when the control belongs to that window, it needs to find the control's top-level parent and compare it to the target window (which is very simple).
User avatar
jeeswg
Posts: 5152
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Gui Controls | Gui.FocusedCtrl | ControlGetFocus | ComboBoxEx

07 Oct 2018, 21:38

- Updating scripts, I noticed that ControlGetFocus (ClassNN) is now pretty verbose:

Code: Select all

;before:
vCtlClassNN := ControlGetFocus("A")

;after:
vCtlClassNN := ControlGetClassNN(ControlGetFocus("A"))

;suggestion (new function):
vCtlClassNN := ControlGetFocusClassNN("A")

;also (2 further functions):
vCtlClass := ControlGetFocusClass("A")
vCtlClass := ControlGetClass(vCtlClassNN, "A")
- While doing the updates, I noticed how often I want the focused control *class*, either using WinGetClass, or replacing/ignoring the NN.
- So regularly in fact, that separate functions would be used far more frequently than other existing 'Control' functions.

- Summary:

Code: Select all

ControlGetFocusClass - e.g. is it an Edit control [proposal]
ControlGetFocusClassNN - e.g. is it the right Edit/listview [proposal, used to exist as 'ControlGetFocus']
ControlGetFocus (Hwnd) [exists]

ControlGetClass - a possibility [proposal]
ControlGetClassNN [exists]
ControlGetHwnd [exists]

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: SAbboushi and 1 guest