Proposed New GUI API for AutoHotkey v2

Discuss the future of the AutoHotkey language
User avatar
fincs
Posts: 500
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Proposed New GUI API for AutoHotkey v2

23 Mar 2014, 17:13

GUI is in my opinion one of the key things that need to be redesigned for v2. The following is a proposed design for a modern object-based Gui API for AutoHotkey v2, which tries to emulate as closely as possible the simplicity of the old v1.x Gui commands, while at the same time updating the design to OOP to allow for greater flexibility and organization.

EDIT: Lexikos-supplied test build (Updated 24/3/2017)

Code: Select all

Gui commands:
-------------

GuiCreate([Title, Options, FuncPrefixOrObj])
  Creates a new Gui object (Same as v1 Gui, New).
  The third parameter specifies the function prefix or object to bind events to.
  If a function prefix is specified, Gui events such as OnClose or OnDropFiles are automatically bound.
  If an object is specified, it is used as an event sink; meaning event names are used as method names
  to invoke on the object.
  This mechanism is both similar to that of ComObjConnect() and the old v1 +Label system.

GuiFromHwnd(Hwnd [, RecurseParent := false])
  Returns the Gui object associated with the specified Gui HWND.
  If RecurseParent is true, the closest parent to the specified HWND that is a Gui is automatically
  searched for and retrieved.

GuiCtrlFromHwnd(Hwnd)
  Returns the Gui Control object associated with the specified Gui Control HWND.

Gui object:
-----------

gui.Destroy()
  Destroys the window. Same as v1 Gui, Destroy.
  If the Gui is closed and there are no references to the Gui object, the Gui is destroyed.

gui.Add(Ctrl [, Text, Options])
gui.AddCtrl([Text, Options]) where Ctrl is a valid control type
  Adds a new control to the Gui. (Text was renamed to Label).
  In v1.x, some control types such as ListView accept a string with a changeable delimiter (by default |).
  In v2, arrays are also supported, and this obviates the need to support changing the delimiter.
  The g-label option now specifies the function or method name to call in order to receive
  events from the control (equivalent to v1 g-labels).
  The 'v' option is now repurposed to give an explicit name to the control, instead of binding a variable.
  For Button controls, if the g-label is omitted, the same v1 transformation rules are applied to
  automatically generate a function or method name (expanded to accomodate for stricter identifier
  names).
  Returns a GuiControl object.

gui.Show([Options, Title])
  Same as v1 Gui, Show

gui.Submit([Hide := true])
  Returns an associative array containing the values of all the controls that have been explicitly named.
  Similar to v1 Gui, Submit

gui.Hide()
gui.Cancel()
  Same as v1 Gui, Hide (Cancel)

gui.SetFont([Options, FontName])
  Same as v1 Gui, Font

gui.BgColor := color
gui.CtrlColor := color
  Same as v1 Gui, Color

gui.MarginX := value
gui.MarginY := value
  Same as v1 Gui, Margin

gui.Opt(options)
gui.Options(options)
  Same as v1 Gui +/-Option1 +/-Option2

gui.Menu := menuObj
  Same as v1 Gui, Menu

gui.Hide()
gui.Minimize()
gui.Maximize()
gui.Restore()
  Same as v1 Gui, Hide/Minimize/Maximize/Restore

gui.Flash([onOrOff := true])
  Same as v1 Gui, Flash [, Off]

gui.Hwnd
  Retrieves the Gui's Hwnd

gui.Title
  Sets or retrieves the Gui's title

gui.Control[Name]
  Retrieves the GuiControl object associated with the specified name, ClassNN or HWND.
  Compare:
    GuiControl,, Static1, SomeValue
    gui.Control["Static1"].Value := "SomeValue"

gui.FocusedCtrl
  Returns the GuiControl object of the focused control, or an empty string.

gui._NewEnum()
  Iterates through the Gui's controls.
  The first output variable is the HWND, and the second is the control object.

gui.OnClose
gui.OnEscape
gui.OnSize
gui.OnContextMenu
gui.OnDropFiles
  These properties can be get/set in order to change the event handlers, especially for
  binding an arbitrary callable object.

Events:

OnClose(gui)
OnEscape(gui)
OnSize(gui, eventInfo, width, height)
OnContextMenu(gui, control, eventInfo, isRightClick, x, y)
OnDropFiles(gui, fileArray, control, x, y)

OnClose now has a return value. If OnClose() returns a false value (such as nothing), the Gui is closed
(as if the OnClose event handler did not exist). If it returns a true value, the Gui is not closed.

GuiControl object
-----------------

ctrl.Type
  Retrieves the type of the control. (Not implemented yet)

ctrl.Hwnd
  Retrieves the HWND of the control.

ctrl.Name
  Retrieves or sets the explicit name of the control.

ctrl.ClassNN
  Retrieves the ClassNN of the control.

ctrl.Gui
  Retrieves the control's Gui parent.

ctrl.Event
  Retrieves or sets the control's event handler, which can be either a function/method name
  or an arbitrary callable object.

ctrl.Opt(options)
ctrl.Options(options)
  Same as v1 GuiControl, +/-Option1 +/-Option2

ctrl.Move(pos[, draw:=false])
  Same as v1 GuiControl Move(Draw)

ctrl.Focus()
  Same as v1 GuiControl Focus

ctrl.Choose(Value [, additionalActions := 0])
  Same as v1 GuiControl Choose(String). If Value is a pure integer, it is an item index;
  otherwise it is treated as the item text. additionalActions replaces the pipe-prepending
  mechanism of the v1 command (instead of prepending N pipes, this parameter is set to N).

ctrl.UseTab([Value, exactMatch := false])
  Same as v1 Gui Tab. If Value is a pure intege, it is a tab index; otherwise it is text.
  Omit all parameters to stop adding controls inside this Tab control.

ctrl.Value
  Same as v1 GuiControl/Get with no subcommand

ctrl.Text
  Same as v1 GuiControl/Get Text

ctrl.Enabled
  Specifies whether the user can interact with the control

ctrl.Visible
  Same as v1 GuiControl/Get Visible

ctrl.Focused
  Same as v1 GuiControlGet Focused. (Not implemented yet)

ctrl.Pos
  Returns the position in an object containing x,y,w,h fields.

Control event function:
  ControlEvent(ctrl, guiEvent, eventInfo, extra)
  The 'extra' parameter is only passed on Link or Custom control events.

LV_/TV_/SB_ functions are now methods of LV/TV/SB control objects.

tv.GetText() and lv.GetText() now return the text directly instead of having an
OutputVar (failure results in an exception being thrown).

-------------------------------------------------------------------------------

; Converted Example: Simple image viewer:

GuiCreate gui, ImageViewer, Resize, MyGui_
gui.AddButton &Load New Image, Default
radio := gui.AddRadio("Load &actual size", "ym+5 x+10 checked")
gui.AddRadio Load to &fit screen, ym+5 x+10
pic := gui.AddPic(, "xm")
gui.Show()

; Due to v2's Persistence rules, it is no longer necessary to include a
; GuiClose() { ExitApp } event handler in order for the script to properly close.

MyGui_ButtonLoadNewImage() ; using automatic event handler name
{
  global gui, radio, pic
  FileSelect file, a,, Select an image:, Images (*.gif; *.jpg; *.bmp; *.png; *.tif; *.ico; *.cur; *.ani; *.exe; *.dll)
  if !file
    return
  if radio.Value = 1 ; Display image at its actual size.
  {
    Width := 0
    Height := 0
  }
  else ; Second radio is selected: Resize the image to fit the screen.
  {
    Width := A_ScreenWidth - 28  ; Minus 28 to allow room for borders and margins inside.
    Height := -1  ; "Keep aspect ratio" seems best.
  }
  pic.Value := "*w%width% *h%height% %file%"  ; Load the image.
  gui.Show xCenter y0 AutoSize, %file% - Image Viewer  ; Resize the window to match the picture size.
}

-----------------------------------------------------------------------

; Converted Example: A moving progress bar overlayed on a background image.

GuiCreate gui, Progress Example,, MyGui_
gui.BgColor := "White"
gui.AddPicture %A_WinDir%\system32\ntimage.gif, x0 y0 h350 w450
gui.AddButton Start the Bar Moving, Default xp+20 yp+250
MyProgress := gui.AddProgress(, "w416")
MyText := gui.AddLabel(, "wp")  ; wp means "use width of previous".
gui.Show()

MyGui_ButtonStartTheBarMoving()
{
  global MyProgress, MyText
  Loop Files, %A_WinDir%\*.*
  {
    if A_Index > 100
      break
    MyProgress.Value := A_Index
    MyText.Value := A_LoopFileName
    Sleep 50
  }
  MyText.Value := "Bar finished."
}
fincs
Windows 10 x64 Build 17134 / AutoHotkey v1.1.29.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]
User avatar
nnnik
Posts: 4187
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

24 Mar 2014, 00:32

What about Tabs?
In addittion to the normal Stuff

Code: Select all

tabctrl.addtab([name]) ;adds a new tab 
tabctrl.removetab([name]) ;removes a tab
tabctrl.activetab ;contains the name of the currently active tab. (can be set)
tabctrl.tab ;contains all the tab objects
tabctrl.addtotab(ctrl,name) ; adds ctrl to tab name
tabctrl.addtotabname(ctrl)
tabctrl.addctrltotab(name)
tabctrl.addctrltotabname()
Recommends AHK Studio
lexikos
Posts: 6404
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Proposed New GUI API for AutoHotkey v2

24 Mar 2014, 03:13

Putting aside whether moving to object-oriented APIs is really what's best for the average user, I don't see myself having sufficient motivation to implement it before v2.0 (if at all).

Is there any built-in functionality or change that would be needed to make this easier to do (in script)?
User avatar
fincs
Posts: 500
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

24 Mar 2014, 06:58

As I said in my other thread, I may try to implement any of my ideas, it's then up to you if you accept them. I posted this now so that people can exactly discuss if this is worth it and how it should be done before any of us implement anything. Currently AFC (which has a similar but more complex API) has been developed, however many ugly workarounds had to be used to deal with old-fashioned patterns such as associated variables, g-labels or the way TV_ and SB_ and LV_ functions identify the control they operate on.
fincs
Windows 10 x64 Build 17134 / AutoHotkey v1.1.29.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]
Coco
Posts: 771
Joined: 29 Sep 2013, 20:37
GitHub: cocobelgica

Re: Proposed New GUI API for AutoHotkey v2

06 Jun 2014, 15:27

+1
If this were to get implemented, I assume +Parent can be implemented as follows: +ParentVarContainingGuiObject or +ParenthWndOfParent. Also this retires A_Gui, A_GuiControl, A_GuiWidth, A_GuiHeight, and the like.
User avatar
fincs
Posts: 500
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

06 Jun 2014, 15:40

Coco wrote:If this were to get implemented, I assume +Parent can be implemented as follows: +ParentVarContainingGuiObject (...)
No. The point is to eradicate these kinds of clumsy and fiddly behaviours that involve variable names being passed in string form or some other kind of unorthodox way. I'd allow +ParenthWndOfParent and also the following:

Code: Select all

gui.Parent := GuiObjOrHwnd
The same also applies for Owner. Note that in v2, the construct +Parent%gui.Hwnd% is perfectly legal.
Coco wrote:Also this retires A_Gui, A_GuiControl, A_GuiWidth, A_GuiHeight, and the like.
Exactly. I count 7 BIVs less to support, implement and document.
fincs
Windows 10 x64 Build 17134 / AutoHotkey v1.1.29.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]
Coco
Posts: 771
Joined: 29 Sep 2013, 20:37
GitHub: cocobelgica

Re: Proposed New GUI API for AutoHotkey v2

06 Jun 2014, 15:48

I assume that the Gui options are accessible as object properties...? e.g.:

Code: Select all

gui.Style := style
gui.ExStyle := exstyle
Or are they limited to gui.Options()?
User avatar
fincs
Posts: 500
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

06 Jun 2014, 15:56

I hadn't thought of that as of yet; but probably some of these options would indeed be accessible via object properties; for convenience's sake.
fincs
Windows 10 x64 Build 17134 / AutoHotkey v1.1.29.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]
Coco
Posts: 771
Joined: 29 Sep 2013, 20:37
GitHub: cocobelgica

Re: Proposed New GUI API for AutoHotkey v2

06 Jun 2014, 16:02

The advantages are definitely evident:
  • No more awkward Gui %GuiNameOrNumberOrHwnd%:CommandHere
  • Gui Default I believe is no longer needed when working with an object reference
  • No more GuiControl %Gui%:CommandHere, Control as well
  • And other Gui command quirks
So there is no destroy() method considering that if there is one, the window is destroyed but the then object points to a non-existing window.
User avatar
nnnik
Posts: 4187
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

07 Jun 2014, 02:49

fincs wrote:
Coco wrote:If this were to get implemented, I assume +Parent can be implemented as follows: +ParentVarContainingGuiObject (...)
No. The point is to eradicate these kinds of clumsy and fiddly behaviours that involve variable names being passed in string form or some other kind of unorthodox way. I'd allow +ParenthWndOfParent and also the following:

Code: Select all

gui.Parent := GuiObjOrHwnd
The same also applies for Owner. Note that in v2, the construct +Parent%gui.Hwnd% is perfectly legal.
Coco wrote:Also this retires A_Gui, A_GuiControl, A_GuiWidth, A_GuiHeight, and the like.
Exactly. I count 7 BIVs less to support, implement and document.
I'd rather use it that way:

Code: Select all

MDI.Subcontrolorsubgui:=Subgui
Recommends AHK Studio
User avatar
fincs
Posts: 500
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

07 Jun 2014, 04:33

nnnik wrote:I'd rather use it that way:
That goes against the current v1.x Gui design and also doesn't allow a Gui to have multiple children.
fincs
Windows 10 x64 Build 17134 / AutoHotkey v1.1.29.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]
User avatar
nnnik
Posts: 4187
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

07 Jun 2014, 06:14

That goes against the current v1.x Gui design.
Thats the point.
We want to change the current design, or?
Also this seems to be an design thats pretty easy to understand and gives huge power, since 1 GUI with all of its subguis and subcontrols would be packed into one object.
and also doesn't allow a Gui to have multiple children.
I think I didnt fully explain it. My fault:

Code: Select all

MyGUI[Any_SubGUI_Name_Or_Control_Name]:=new Any_SubGUI_Or_Control_Type(Parameters*)
Recommends AHK Studio
User avatar
fincs
Posts: 500
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

07 Jun 2014, 06:29

nnnik wrote:Thats the point.
We want to change the current design, or?
No. The point is to replace the Gui commands with an OOP Gui API that does not have any of the quirks/eccentricities of the old Gui command set; yet retaining familiarity, ease of use and certain aspects of AutoHotkey's Gui implementation. Note how the examples I provided are completely OOP, yet still very familiar and similar to v1.x Gui code; even more so if object command syntax is introduced.
fincs
Windows 10 x64 Build 17134 / AutoHotkey v1.1.29.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]
User avatar
evilC
Posts: 4697
Joined: 27 Feb 2014, 12:30

Re: Proposed New GUI API for AutoHotkey v2

09 Jun 2014, 17:42

I totally agree.
To overhaul the rest of the language into a consistent syntax, but leave the GUI commands tied to the old (v)label system would be a shame.

In the process, I would also love to see the hotkey GUI control overhauled. It needs to be able to recognize any key / mouse button / joy button combination that the hotkey() command or hotkey:: label supports. This is certainly possible (at least the keyboard and mouse part), as I have written my own version that does it.

Oh, and we also need to make sure you can make a proper GUI with scrollbars using it. Lexikos' proof-of-concept seems to work with v2, so hopefully we should be able to find a solution there.
toralf
Posts: 602
Joined: 27 Apr 2014, 21:08
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

10 Jun 2014, 23:07

fincs wrote:The point is to replace the Gui commands with an OOP Gui API that does not have any of the quirks/eccentricities of the old Gui command set; yet retaining familiarity, ease of use and certain aspects of AutoHotkey's Gui implementation.
fincs, quite frankly at first I was shocked. It felt in the first minute as the same route that AutoIt took when Chris decided to make his fork. Chris kept the command style while AutoIt went for more functions. (At least this is what i remember).

I have used the command style for years now and maybe I have overly accustomed myself with its quirks. So looking from maybe with a little more distance this approach is at least worth to discuss.

First some questions:
Do you plan to keep the old command style available in v2 or would this be a replacement?
How would controls be added to different tabs?
How would tree view & list view controls be filled with data?
How would list view controls be filled with pictures?
How would resize of controls work compared to anchor() for v1?
How could the title of a GUI be changed later?
Will the controls have more features, e.g. like LVA wrapper for cell or row coloring/picture or progress bar in cell/?
How would tooltip work when the mouse hoovers over a control?

These are only the first questions that came to my mind. I'm not convinced yet that this will be the right step because in my feeling v2 becomes very function heavy but I also can sense some advantages.
I would appreciate if the 'normal' new user could use this new approach easily. Granted that the old style wasn't easy either in some cases. And that old users like me can take some experience over.
ciao
toralf
User avatar
fincs
Posts: 500
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

11 Jun 2014, 04:30

toralf wrote:(...)I'm not convinced yet that this will be the right step because in my feeling v2 becomes very function heavy but I also can sense some advantages.
I would appreciate if the 'normal' new user could use this new approach easily. Granted that the old style wasn't easy either in some cases. And that old users like me can take some experience over.
First of all, AutoHotkey v2 aims to remove language quirks, such as the division between commands and functions. Currently everything can be called using both command and function syntax (except for object methods and properties; support for which is planned according to Lexikos). So it doesn't matter whether new functions or commands are added: they're the same thing. Yes, you can now call DllCall, RegExMatch, RegExReplace and every single other built-in function and even user-defined function using command syntax.
toralf wrote:Do you plan to keep the old command style available in v2 or would this be a replacement?
This proposed design is intended as a replacement. As such, and in order not to alienate current AHK users, I designed it so that it stays as similar/parallel as possible as the old Gui API. Converting code to use the new Gui API is literally a matter of doing some minor tweaks to each line that uses a Gui command/function. Almost everything has a 1:1 correspondence.
toralf wrote:How would tree view & list view controls be filled with data?
The TV_, SB_ and LV_ functions would stay the same, except for the fact that they are now methods of TreeView, StatusBar and ListView control objects.
toralf wrote:How would controls be added to different tabs?
Same way as it is now, unless somebody proposes a better and doable design.
toralf wrote:How would list view controls be filled with pictures?
How would resize of controls work compared to anchor() for v1?
Will the controls have more features, e.g. like LVA wrapper for cell or row coloring/picture or progress bar in cell/?
How would tooltip work when the mouse hoovers over a control?
This redesign is not intended to bring new features. It is mostly an interface change.
toralf wrote:How could the title of a GUI be changed later?
Same way as it is now, with gui.Show(). Additionally a gui.Title property could be added, for convenience's sake.
fincs
Windows 10 x64 Build 17134 / AutoHotkey v1.1.29.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]
lexikos
Posts: 6404
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Proposed New GUI API for AutoHotkey v2

11 Jun 2014, 22:03

fincs wrote:First of all, AutoHotkey v2 aims to remove language quirks,
That isn't strictly true. The core goal is "to improve the usability and convenience of the language and command set by sacrificing backward compatibility," which has in some cases meant removing language quirks. An AutoHotkey without quirks isn't AutoHotkey at all.
User avatar
fincs
Posts: 500
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

12 Jun 2014, 04:18

lexikos wrote:An AutoHotkey without quirks isn't AutoHotkey at all.
The same can be said about just about any other language. What I really meant was reducing the number of quirks to a "sustainable" level, like that found in other programming languages.
fincs
Windows 10 x64 Build 17134 / AutoHotkey v1.1.29.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]
toralf
Posts: 602
Joined: 27 Apr 2014, 21:08
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

18 Jul 2014, 11:03

Following are a set of questions, proposals and braindumps for discussion.

In the first post I was missing to get the focused control. Proposal: gui.FocusedCtrl returning the ctrl object in focus. Another option would be to extend the gui.Control[Name] to gui.Control[Focused|ClassNN|Hwnd|vLabel].

I do not realy like the gui._NewEnum() more intuitive to me seems gui.controls leading to For hwnd,CtrlObj in gui.Controls

For Focus are two variants mentioned: ctrl.Focus() and ctrl.Focused
But for ctrl.Enabled and ctrl.Visible the post states they fullfill GuiCrontol and GuiControlGet
I propose to combine the focus variants as well to fulfill Set and Get.
I assume ctrl.Enabled := True sets a controlled enabled, and that If ctrl.Enabled is true if the control is enabled, correct?
I hope the same Set and Get mechanism applies to gui.Hide(), gui.Minimize(), gui.Maximize(), gui.Restore()

On ctrl.Move(pos) and ctrl.MoveDraw(pos):
What is Pos? An array [ 11, 22, 23, 45], an assosiated array [ x: 11, y: 22, w: 23, h: 45], a string "x11 y23 w23 h45" or are all possible?
Couldn't these two functions be combined to ctrl.Move(pos, Draw := False) with 'Draw' being normaly 'false' for most controls and 'true' for Groupboxes? The optional parameter 'Draw' would still provide the possibility to override the defaults.

gui.Flash(), gui.FlashOff() could as well be combined to gui.Flash(On := True)

What does ctrl.Gui return? The Hwnd of the gui or a reference to the GuiObject? I assume the reference to the gui object, correct?

ctrl.Choose(N) and ctrl.ChooseString(N) could also be combined to ctrl.Choose(N|"String"), with the special case if string is a number, then a special char needs to be added, e.g. a space at the end of the number string or a * like ctrl.Choose(*NumberString).

Regarding GuiFromHwnd(hwnd):
There seems to be no way to get the ctrl object by a hwnd yet.
Wouldn't it be more intuitive to have Hwnd(hwnd) return the object, either gui or control? The the obj.Type shows the type of object.
On the otherhand gui._NewEnum() iterates over all controls. Should there be an super object that allows to operate over all Guis? E.g. For hwnd,GuiObj in ScriptObj.Guis.

I'm aware that my proposals to combine some functions lead to a non 1-to-1 translation between v1 coimmands to v2 functions, but in the long run, I hope these simplifications make the functions more intuitive.

My 2 cents.
ciao
toralf
User avatar
fincs
Posts: 500
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

18 Jul 2014, 11:23

toralf wrote:In the first post I was missing to get the focused control. Proposal: gui.FocusedCtrl returning the ctrl object in focus.
Seems sensible.
toralf wrote:I do not realy like the gui._NewEnum()
That's the necessary method to implement in order for for ctrlObj in gui to work. See NewEnum() and For-loop.
toralf wrote:I propose to combine the focus variants as well to fulfill Set and Get.
I assume ctrl.Enabled := True sets a controlled enabled, and that If ctrl.Enabled is true if the control is enabled, correct?
Seems sensible too, and yes.
toralf wrote:I hope the same Set and Get mechanism applies to gui.Hide(), gui.Minimize(), gui.Maximize(), gui.Restore()
No, because these are actions to be performed on a Gui; not a property.
toralf wrote:On ctrl.Move(pos) and ctrl.MoveDraw(pos):
What is Pos? An array [ 11, 22, 23, 45], an assosiated array [ x: 11, y: 22, w: 23, h: 45], a string "x11 y23 w23 h45" or are all possible?
Couldn't these two functions be combined to ctrl.Move(pos, Draw := False) with 'Draw' being normaly 'false' for most controls and 'true' for Groupboxes? The optional parameter 'Draw' would still provide the possibility to override the defaults.
I'd make both [ x: 11, y: 22, w: 23, h: 45 ] and "x11 y23 w23 h45" possible. Merging Move() and MoveDraw() also looks sensible to me in the way you described.
toralf wrote:gui.Flash(), gui.FlashOff() could as well be combined to gui.Flash(On := True)
OK to me as well.
toralf wrote:What does ctrl.Gui return? The Hwnd of the gui or a reference to the GuiObject? I assume the reference to the gui object, correct?
Indeed, the reference to the Gui object.
toralf wrote:ctrl.Choose(N) and ctrl.ChooseString(N) could also be combined to ctrl.Choose(N|"String"), with the special case if string is a number, then a special char needs to be added, e.g. a space at the end of the number string or a * like ctrl.Choose(*NumberString).
No. In v2 strings and integers are always different types, so there'd be no need to add the * kludge. ctrl.Choose(1) and ctrl.Choose("1") are different things. However in command syntax, all parameters are strings; so I think it'd still be a good idea to have a separate ChooseString() method.
toralf wrote:Regarding GuiFromHwnd(hwnd):
There seems to be no way to get the ctrl object by a hwnd yet.
Yes there is: gui.Control[hwnd]. Due to the way Guis are implemented, retrieving the object associated to a control is only possible if you know which Gui they belong to.
fincs
Windows 10 x64 Build 17134 / AutoHotkey v1.1.29.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 5 guests