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.