Proposed New GUI API for AutoHotkey v2

Discuss the future of the AutoHotkey language
just me
Posts: 4685
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] [Expand] [Download] GeSHi © Codebox Plus

Remaining with AHK 1.1.25.02 until v2 will become beta.
lexikos
Posts: 5410
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

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: 2216
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] [Expand] [Download] GeSHi © Codebox Plus



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

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.php?f=5&t=29293&p=138253#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.
lexikos
Posts: 5410
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

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: 4685
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:
Remaining with AHK 1.1.25.02 until v2 will become beta.
guest3456
Posts: 2022
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: 2216
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.
just me
Posts: 4685
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] [Download] GeSHi © Codebox Plus

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
Remaining with AHK 1.1.25.02 until v2 will become beta.
lexikos
Posts: 5410
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

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: 189
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] [Download] GeSHi © Codebox Plus

gui.x
gui.y
gui.width
gui.height
just me
Posts: 4685
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?
Remaining with AHK 1.1.25.02 until v2 will become beta.
lexikos
Posts: 5410
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Proposed New GUI API for AutoHotkey v2

19 Apr 2017, 21:16

GuiFromHwnd/GuiCtrlFromHwnd.
just me
Posts: 4685
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?
Remaining with AHK 1.1.25.02 until v2 will become beta.
lexikos
Posts: 5410
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

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: 2187
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: 4685
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] [Expand] [Download] GeSHi © Codebox Plus

  • v2:

    Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

The v2 code appears to be somewhat more complicated. Also, Gui.Name := "MyGui" might be useful i some cases.
Remaining with AHK 1.1.25.02 until v2 will become beta.
lexikos
Posts: 5410
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

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] [Download] GeSHi © Codebox Plus

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: 5410
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

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: 5410
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

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: 2187
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 v2 Development”

Who is online

Users browsing this forum: No registered users and 2 guests