Proposed New GUI API for AutoHotkey v2

Discuss the future of the AutoHotkey language
just me
Posts: 9423
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

08 Apr 2017, 09:57

lexikos wrote:Changed Gui.Submit() to ignore controls which don't accept input.
In which cases would it be necessary to use Gui.Submit()? The controls seem to report their current contents without it. Ans also, 'associated variables' don't seem to exist.

Code: Select all

MyGui := GuiCreate("Test")

C := MyGui.AddText("Add some text clickable to be shown in the GUI", "+Border vText")
C.Event := "LabelClicked"

C := MyGui.AddEdit("Add an Edit control", "vEdit")

C := MyGui.AddRadio("Radio control", "vRadio")

C := MyGui.AddButton("Show Controls")
C.Event := "ButtonClicked"

MyGui.Show()

Return

LabelClicked(Ctrl, Event, EventInfo) {
   MsgBox("Label clicked!")
}

ButtonClicked(Ctrl) {
   ; Ctrl.Gui.Submit(0)
   MsgBox("Text: " . Ctrl.Gui.Control["Text"].Value . "`n`n"
        . "Edit: " . Ctrl.Gui.Control["Edit"].Value . "`n`n"
        . "Radio: " . Ctrl.Gui.Control["Radio"].Value . "`n`n")
}
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

08 Apr 2017, 20:10

just me wrote:In which cases would it be necessary to use Gui.Submit()?
It is never necessary, just convenient. Submit gives you a snapshot of the "form" in a single associative array. It is mostly analogous to submitting a web form. You must store the return value, otherwise there is no point in calling Submit(0):
gui.Submit([Hide := false])
Returns an associative array containing the values of all the controls that have been explicitly named.
If you store the result in Form, Ctrl.Gui.Control["Edit"].Value would become Form.Edit. The more controls you have, the more value this feature has. I suppose it was the same in v1: Gui Submit was always redundant, because you could always use GuiControlGet to get the control's value.

The Text control is not submitted, because it does not accept user input. v1 is the same.
Ans also, 'associated variables' don't seem to exist.
Of course they don't.
fincs wrote:The 'v' option is now repurposed to give an explicit name to the control, instead of binding a variable.
(Originally fincs removed the v option and Gui Submit, but added them in their current form following my suggestion.)
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Proposed New GUI API for AutoHotkey v2

09 Apr 2017, 00:22

This 9-page topic was a good Thursday evening read.

==================================================

LIST OF POTENTIAL OBJECT PROPERTIES/METHODS

I have had some ideas for a window object, with syntax such as below, which could act as a useful checklist of properties for the GUI API:

Basic tip: take into consideration all the WinXXX and ControlXXX functions.

None of these names are 'set in stone':

Code: Select all

oWin := WinObjFromID(hWnd)
oWins := WinObjFromClass("Notepad")

oWin.containswin[hWnd]
oWin.containsctl[hWnd]
oWins.count
oWin.hwnd
oWins[1].hwnd
oWin.pname ;process name
oWin.ppath ;process path
oWin.pid ;process ID
oWin.pdesc ;description
oWin.ppriority
oWin.pbits ;e.g. 32/64
oWin.pcreated
oWin.title ;the title the last time it was retrieved, if not retrieved yet, get title now
oWin.title_r ;'refresh', get current title (cf. 'submit' principle)
oWin.pos_cs ;comma-and-space-separated
oWin.pos_k ;comma-and-space-separated
oWin.pos_c ;comma-separated
oWin.pos_s ;space-separated
oWin.pos_p ;pipe-separated
oWin.pos_l ;with letters
oWin.pos_csl ;with letters e.g. 'x0, y0, w0, h0'
oWin.pos_r ;or oWin.pos_refresh or oWin.pos_update 'refresh', get current position
oWin.pos_c["xywh"]
oWin.pos_c["xyrb"]
oWin.posrelative[hWnd2] ;relative to another window, screen/window/client
oWin.xy_r
oWin.wh_r
oWin.parent
oWin.owner
oWin.childcount ;or oWin.children.length
oWin.class
oWin.classnn (relative to parent)
oWin.isvisible
oWin.isenabled
oWin.style
oWin.exstyle
oWin.minmaxstate ;or oWin.minmax
oWin.transcolor
oWin.transvalue ;or oWin.translevel or oWin.transparency
oWin.ontop
oWin.exists
oWin.isactive ;or oWin.isfocused
oWin.children
oWin.children[1].hwnd
oWin.children[1].classnn
oWin.region
oWin.iswin ;determined when object created
oWin.isctl ;determined when object created

oWin.minimize() ;(minimise)
oWin.maximize() ;(maximise)
oWin.restore()
oWin.center() ;or oWin.movecenter (centre)
oWin.show()
oWin.hide()
oWin.kill()
oWin.close()
oWin.redraw()
oWin.ctlfocus()
oWin.ctlselect()
oWin.send()
oWin.flash()

(where oCtl has same object blueprint as oWin)

oCtl.text ;text last time it was retrieved, or current text if it wasn't retrieved before
oCtl.text_lastornow ;same as above
oCtl.text_r ;or oCtl.text_now retrieve current text
oCtl.text_last ;text last time it was retrieved, or nothing, if it hasn't been retrieved yet
oCtl.textitems("10,1-4", "`r`n") ;get item text in a certain order with a certain delimiter (handle selected/focus/column)
oCtl.rangestart ;or oCtl.range1 or oCtl.rangeleft
oCtl.rangeend ;or oCtl.range2 or oCtl.rangeright
oCtl.rangeanchor
oCtl.rangeactive
oCtl.rangetext ;or oCtl.textsel (selected text)
oCtl.linestart
oCtl.lineend
oCtl.linecount
oCtl.linetext
oCtl.col ;column
oCtl.ischecked ;(is ticked)
oWin.bkcolor ;name based on SetBkColor function (colour)
oWin.bkcolor_rgb ;name based on SetBkColor function (colour)
oWin.bkcolor_bgr ;name based on SetBkColor function (colour)
oCtl.fontcolor
oCtl.fontcolor_rgb
oCtl.fontcolor_bgr
oCtl.hfont
oCtls.text_r ;update text stored value for controls

oCtl.choose()
oCtl.choosestring()
oCtl.focus()
oCtl.select()
oCtl.deselect()
oCtl.dodefaultaction()
oCtl.moverelative() ;some other name probably
oCtl.check()
oCtl.uncheck()
oCtl.showdropdown()
oCtl.hidedropdown()
oCtl.itemdel()
oCtl.editpaste()

things like this can be handy
oWin.pos_s := "100,100,300,300"
oWin.pos_cs := "100, 100, 300, 300"
oWin.pos_s := "x100 y100 w300 h300" (where letters are ignored)
oWin.pos_parse := "w300 h300 x100 y100" (where letters are not ignored)
==================================================

LINKS

I may have missed the relevant page, but I haven't found good information regarding key GUI issues in AHK v1/v2: key combinations that cause beeps in a GUI, how to properly define hotkeys for a GUI, and how AutoHotkey handles multiple GUIs or MsgBoxes/InputBoxes, since multithreading is not possible.

[beeps + hotkeys]
send keys to a GUI window/control without causing beeps (+ the standard way to define an AHK GUI hotkey) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=29940

[threads]
An attempt at a script that creates MsgBoxes/InputBoxes for other scripts - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 53#p138253

==================================================

AREAS OF CONCERN (FIX AUTOHOTKEY V1)

CLASS NAME/NO ICON
- ability to create a GUI window based on a WNDCLASS/WNDCLASSEX struct, or to take ownership of a window that the user created by other means
... e.g. choose GUI class name, specify no icon

FONTS
- make it easy to resize/reposition controls based on a font size
... and thus easy to respond to ^{WheelUp} / ^{WheelDown}
- what is being done regarding calculating dimensions based on text/font/control size (e.g. via DrawTextEx)?
- how are fonts handled (is there still a limit to the number of hFonts that can be created)?

INTERNAL/EXTERNAL CONTROLS
- is there the ability to use the same methods for internal/external controls?
(E.g. AHK has the ability to interact with internal listviews/treeviews, it should have all those same abilities for interacting with external treeviews, I am working on a library to do this.)
(I would want to use the same object methods for both internal and external windows/controls.)

CONTROL TYPES
- what control types are supported?

FILESELECT
- does FileSelect have the option to choose whether to display the prompt in pre/post-Vista style?

#PERSISTENT
- what is the situation regarding #Persistent?

SYNTAX
- do listviews still have all the quirky letters syntax?

MESSAGE QUEUE
- options/tips for taking more/complete control of the message queue, versus letting AHK look after it (i.e. good documentation on how to override what the GUI API does for special situations)

[A summary of my views regarding the problems with the AHK v1 Gui command]
GUI COMMANDS: COMPLETE RETHINK - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=25893

==================================================

AREAS OF CONCERN (GENERAL)

SPREADSHEET CONTROL
- what is our current best option for a spreadsheet control?

EXAMPLES, PROGRESS/SPLASHIMAGE
- is there a working example for the Progress/SplashImage commands?
- how many of the AHK documentation GUI examples have been recreated?

MULTITHREADING
- what advantages do AHK default functions have over custom functions made by users e.g. regarding multithreading?

CONVERSION
- how easy will it be to convert from the Gui command to the new API?

V. OTHER PROGRAMMING LANGUAGES
- do other programming languages use a GUI API like this one, how 'quirky' is it, how easy is it to learn/use for a beginner who is proficient in a different language
- one guiding principle could be to write AHK code as though it was pseudocode for another language such as C++, so that it could be converted to another language relatively easily, if desired
- any considerations regarding GUIs that are cross-platform (i.e. marrying AHK and Linux)

==================================================

SOME NICE GUI EXAMPLES CITED IN THIS TOPIC

Dynamic GUI Demo
http://screencast-o-matic.com/watch/c2jec3nK4Z
Narrated GUI Demo
http://screencast-o-matic.com/watch/c2jeYjnKgC
Cheers evilC.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

09 Apr 2017, 02:34

jeeswg,

Please take more care to keep the content of your posts on-topic.

Please avoid asking vague questions.

Please avoid asking questions that you can easily answer yourself by reading the topic or performing your own testing.

Your posts read like a list of rough notes-to-self. Please keep such notes to yourself until you have thought them through and are able to write about them more coherently, then post in a relevant topic, or start a new one.

I am losing my patience with your style of posting, and becoming less inclined to read your posts. (Although I must admit that's partly because I often don't sympathise with the content, through no fault of yours.) However, I have read through your post and I don't plan to address any of your concerns specifically. If you have a specific request or suggestion that you want me to consider, you will have to make a better case for why it should be implemented, why in v2, and post in a relevant place (which may or may not be this topic). However, I make no promises.

As an example of "why in v2", GuiCreate() and Gui v1 already have the provision for allowing new options to be added without breaking scripts. An obvious way to support changing the class name of a Gui would be to provide an option for Gui New or GuiCreate. There is no apparent risk of breaking scripts and no apparent impact to any other API, and therefore no reason to consider implementing it as part of v2.0.

ListView "quirky letter syntax" may be addressed as part of implementing the OnEvent() function I described previously, if I choose to implement it; not that I think the A_GuiEvent values particularly need addressing, assuming that's even what you are talking about.
just me
Posts: 9423
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

09 Apr 2017, 03:00

lexikos wrote:Submit gives you a snapshot of the "form" in a single associative array.
Sorry, I missed that. :facepalm:
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Proposed New GUI API for AutoHotkey v2

09 Apr 2017, 09:31

lexikos wrote: I am losing my patience with your style of posting, and becoming less inclined to read your posts.
multiple people here have told him the same thing, multiple times. he refuses to listen. he was run off of stackoverflow for the same nonsense and claims that they are unwelcoming. i have his posts on ignore, which is unfortunately because sometimes he does have the occasional good idea

User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Proposed New GUI API for AutoHotkey v2

09 Apr 2017, 20:32

@lexikos
I've made some comments regarding minimal GUI documentation and functionality considerations for a 'Proposed New GUI API for AutoHotkey v2', in a simple easy-to-read format, with the minimum of unnecessary detail, that is all.

I've done a lot of reading and testing, I don't want to do any more, this approach still has too many AHK v1-style quirks in it. I won't be using it, and I'll be sticking to my own GUI functions. A project that I started in a small way, but that is now gaining traction.

I am no longer concerned about listview 'G-Label Notifications'.

My suggestions are normally quite self-explanatory, and don't benefit from re-expression. If it is not *necessary* that the File loop should handle long filenames, then indeed, it is not necessary. You are very minimalist, actually, so am I. Perhaps arguments like ease of learning, ease of use, ease of sharing code on forums, consistency ('Fixed registry loops to support subkey names longer than 259'), recording usage data, and not removing functionality, don't wash with you, so such proposals won't get a good hearing, and that's fine.

@guest3456
Interesting comments.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
just me
Posts: 9423
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

11 Apr 2017, 09:29

One suggestion, because CtlObject.Focused isn't implemented as yet:

Code: Select all

FocusedControl := GuiObject.Focused ; returns the object of the currently focused control, if any (readonly)
CtlObject.Focused could be used to get the current state of the control (True/False) or be omitted.

Edit: Checking the source code, I just noticed it's already implemented: Gui.FocusedCtrl
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

11 Apr 2017, 17:12

I added Gui.FocusedCtrl to the OP and a note that GuiControl.Focused hasn't been implemented.
sancarn
Posts: 224
Joined: 01 Mar 2016, 14:52

Re: Proposed New GUI API for AutoHotkey v2

12 Apr 2017, 13:37

Something perhaps for the 'wish list'

If a 'Chromium Embedded Framework control' were added that would be ace. This would make HTML GUIs much simpler to make I think... Whether it's easy to implement such a thing though, I'm not certain... Thoughts?


Also would it be possible to get the following properties?:

Code: Select all

gui.x
gui.y
gui.width
gui.height
just me
Posts: 9423
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

19 Apr 2017, 08:15

What's the recommended replacement for A_Gui and A_GuiControl within OnMessage() functions?
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

19 Apr 2017, 21:16

GuiFromHwnd/GuiCtrlFromHwnd.
just me
Posts: 9423
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

20 Apr 2017, 03:22

This doesn't seem to be really sufficient. How do you distinguish between multiple Guis? In v1 it's possible via If (A_Gui = "MainGUI"). Only nameless Guis need additional super-global or global declarations which I'm trying to avoid whenever possible. The new interface requires such declarations in every case because all Guis are nameless. Any chance for a change so you don't need to define globals?
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

20 Apr 2017, 17:05

You can often use the title. If that's insufficient, you can limit the global variables to just one containing an associative array of names. If you have an extreme aversion to global variables, there are various alternatives, such as binding a parameter to the OnMessage callback, or using a static variable (assigned by calling the callback directly).

As I suggested earlier in the topic, a property for accessing the event sink would allow you to associate arbitrary data with the Gui, although it requires you to use methods as event handlers. Typically the class which handles events would also have properties relating to the Gui, so if you're using an event sink, simply having access to it via the Gui object is an elegant solution. Such properties would already be accessible from the event handlers. For differentiating one Gui from another, it's just a matter of storing a name in the object; or checking the object's class with is.

As with GuiControl, I suppose a direct alternative would be to give the Gui a Name property. I think it's redundant, but perhaps providing easier translation is enough reason.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

21 Apr 2017, 00:55

Is it possible to manipulate the object that is returned by GuiFromHwnd/GuiCtrlFromHwnd in a way that allows you to add your own methods to it?
Recommends AHK Studio
just me
Posts: 9423
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

21 Apr 2017, 07:52

Well, so this is how it should be converted in the simplest case?

From the help file:
  • v1.1:

    Code: Select all

    ; Example: The following is a working script that monitors mouse clicks in a GUI window.
    ; Related topic: GuiContextMenu
    
    Gui, Add, Text,, Click anywhere in this window.
    Gui, Add, Edit, w200 vMyEdit
    Gui, Show
    OnMessage(0x201, "WM_LBUTTONDOWN")
    return
    
    WM_LBUTTONDOWN(wParam, lParam)
    {
        X := lParam & 0xFFFF
        Y := lParam >> 16
        if A_GuiControl
            Control := "`n(in control " . A_GuiControl . ")"
        ToolTip You left-clicked in Gui window #%A_Gui% at client coordinates %X%x%Y%.%Control%
    }
    
    GuiClose:
    ExitApp
  • v2:

    Code: Select all

    ; Example: The following is a working script that monitors mouse clicks in a GUI window.
    ; Related topic: GuiContextMenu
    
    Gui1Obj := GuiCreate("Test")
    Gui1Obj.AddText("Click anywhere in this window.")
    Gui1Obj.AddEdit("", "w200").Name := "MyEdit"
    Gui1Obj.Show()
    OnMessage(0x0201, "WM_LBUTTONDOWN")
    Return
    
    WM_LBUTTONDOWN(wParam, lParam, Msg, Hwnd) ; four parameters mode is required
    {
       X := lParam & 0xFFFF
       Y := lParam >> 16
       If (CtlObj := GuiCtrlFromHwnd(Hwnd))
       {
          Control := "`n(in control %CtlObj.Name%)"
          GuiObj := CtlObj.Gui
       }
       Else
          GuiObj := GuiFromHwnd(Hwnd)
       ToolTip("You left-clicked in Gui window %GuiObj.Title% at client coordinates %X%x%Y%.%Control%")
    }
    
    GuiClose()
    {
       ExitApp
    }
The v2 code appears to be somewhat more complicated. Also, Gui.Name := "MyGui" might be useful i some cases.
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

21 Apr 2017, 18:59

I think the example is not a realistic one. In a real world script, I don't think it's common to handle a message applying to all controls and then need the control's name. Usually I think one would need to identify a specific control or group of controls.

You say "somewhat more complicated", but it's only a few extra lines, and most of them are structural. There are two functions in place of two built-in variables. It can be simplified slightly:

Code: Select all

WM_LBUTTONDOWN(wParam, lParam, Msg, Hwnd) ; four parameters mode is required
{
   X := lParam & 0xFFFF
   Y := lParam >> 16
   GuiObj := GuiFromHwnd(Hwnd, true)  ; A_Gui
   if CtlObj := GuiCtrlFromHwnd(Hwnd)  ; A_GuiControl
      Control := "`n(in control %CtlObj.Name%)"
   ToolTip("You left-clicked in Gui window %GuiObj.Title% at client coordinates %X%x%Y%.%Control%")
}
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

21 Apr 2017, 19:19

nnnik wrote:Is it possible to manipulate the object that is returned by GuiFromHwnd/GuiCtrlFromHwnd in a way that allows you to add your own methods to it?
None of the built-in object types allow this.

You can make your own object with whatever interface you like, and use the Gui object internally to implement the functionality. If you use this object as the event sink (third parameter of GuiCreate), you will have direct access to its methods from within the event handlers.

If you do that, you might need a property to retrieve a GUI's event sink (like I mentioned), for OnMessage or other cases where you have a HWND and need the associated (user-defined) object. I'm not sure what to name it, since "event sink" is probably unfamiliar to most users.
lexikos
Posts: 9552
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

21 Apr 2017, 21:29

evilC wrote:I have a question regarding the OnClose() event of GUIs.

This event happens before the Gui is removed from view, but after the Gui object is counted as destroyed (ie calling MyGui.Destroy() throws an "The Gui is destroyed" error)
When I saw the code which throws that error, I suspected that it would cause problems as there may be cases where the script wants to identify a Gui or retrieve some value after its destruction. So when I saw you post this, I made a note to look into it.

I've looked into it and cannot see how what you say can be true. OnClose() is not called when the window is destroyed, only when it receives WM_CLOSE or WM_SYSCOMMAND(SCCLOSE). The error would only happen if you've actually destroyed the Gui or its parent window.
  • If the Gui was destroyed as a result of its parent being destroyed, the Gui wasn't closed, and can't be closed (because it no longer exists), so OnClose() isn't called.
  • If the Gui was destroyed explicitly, obviously you can just do whatever you need to do before destroying it.
  • If the Gui hasn't been removed from view, it still exists and has not been destroyed.
It can be useful to detect when a window is destroyed, but this can already be done with OnMessage monitoring WM_DESTROY, which is processed while the Gui window still exists. I thought about allowing some properties/methods to be accessed after the window is destroyed, but they would have to be carefully reviewed to determine which ones make sense and which ones are safe to use. Hwnd, for instance, must not return the old HWND after the window is destroyed, since HWND values can be reused by the system.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

22 Apr 2017, 01:06

That's a good solution. It's equal to modifying the object directly and avoids the long if else if lines that I did not like in v1.
lexikos wrote:I'm not sure what to name it, since "event sink" is probably unfamiliar to most users.
I think that more users are familiar with "event handler" though it is slightly inappropriate.
Recommends AHK Studio

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: lexikos and 33 guests