Proposed New GUI API for AutoHotkey v2

Discuss the future of the AutoHotkey language
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

27 Apr 2017, 17:04

just me wrote:Afterwards every left click on whatever area of the Gui will raise the same exeption.
This is because the drop-down window's (system-standard) default handling for WM_LBUTTONDOWN is to call SetCapture(), which will capture the mouse even if the drop-down window has been hidden as a result of showing a message box. Once the mouse is captured, messages are routed to that (hidden) window even when you click on other windows. Calling the system MessageBox function or throwing an exception has the same effect in v1 and v2.

Because SetCapture() is called after the message returns, calling ReleaseCapture() first has no effect. Calling it after the message returns does work. Returning a value (not throwing an exception) blocks the default handling, and therefore stops the control from capturing the mouse. However, I think it might be inappropriate for AutoHotkey to default to blocking the message's default handling when an exception is thrown.

WM_LBUTTONDOWN is posted to the window even when I click on an external program, which is supposed to be impossible.
SetCapture wrote:This function cannot be used to capture mouse input meant for another process.
However, activating an external program before returning from the message handler does prevent the window from capturing the mouse.
just me wrote:It's possible to get the HWND of the ListBox window (ComboLBox ) via GetComboBoxInfo(). So it should be possible to get the corresponding Gui control and Gui also.
Exactly what is your point? That GuiFromHwnd() should query every ComboBox the script owns in case the window belongs to one of them? I don't think so. Perhaps there is a more efficient way, but even if so, I think it is outside the scope of the GuiFromHwnd/GuiCtrlFromHwnd functions.
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

28 Apr 2017, 05:14

lexikos wrote:... I think it is outside the scope of the GuiFromHwnd/GuiCtrlFromHwnd functions
It should be mentioned in the docs, then.
User avatar
Ragnar
Posts: 611
Joined: 30 Sep 2013, 15:25

Re: Proposed New GUI API for AutoHotkey v2

28 Apr 2017, 08:50

What do you think about Ctrl.Add(ArrayOrList [, Overwrite := false])?

Old:

Code: Select all

MyListBox.Delete()
MyListBox.Add(List)
New:

Code: Select all

MyListBox.Add(List, true)
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

28 Apr 2017, 10:23

I don't like it. As the name implies, MyListControl.Add() should add items to the list. IMO, the combination

Code: Select all

MyListControl.Delete()
MyListControl.Add(List)
is sufficient as well as clear.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Proposed New GUI API for AutoHotkey v2

28 Apr 2017, 12:25

When I do my GUI object class.

I plan to have the same object class for windows and controls.

At present it would have:
- oWin.AddCtl()
- oCtl.AddItem() for controls likes like listview/treeview/ListBox/ComboBox/toolbar.

I don't mind having things slightly longer for absolute clarity.
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: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

28 Apr 2017, 19:08

Options, Text vs Text, Options

I scanned for Gui Add lines in the documentation and my script collection (mostly my own scripts). There were 418 total Gui Add lines detected (but some lines might have been missed).
just me wrote:Button, Checkbox, Radio, Text, Picture, ListBox, DDL, ComboBox controls without initial contents / captions?
In fact, yes. But only 12 of 274 lines. Sometimes I use Text for output, in which case the value is only set afterward (perhaps repeatedly). Pic is created without initial contents in the "Simple image viewer" example.

Just within the documentation, 12% omitted options, and 17% omitted text. However, supposing that the name (v) and event handler (g) options are replaced with separate parameters, 25% would omit options (i.e. more often than text). That really doesn't help the case for putting options second, since omitting options and specifying a name/event handler would require "", or (empty) , for options either way. Beside that, within my collection, 14% would omit options vs 21% omitting text. So like I said, in my experience, text is omitted more often than options.

The statistics don't represent each control equally, because some controls are used much more often than others. 61% of the lines which had no initial text were Edit controls. Edit controls account for 19% of the sample (i.e. they're very common) and only 36% had Text, while 94% had Options (99% if you include v, which was used by 86% of those Edit controls).

Of the remaining controls, 91% had Text and 86% had options. That's not much difference.

There are a few control types where it stands to reason that Text will be omitted often:
  • TreeView, because Text isn't meaningful.
  • Custom, either because Text isn't meaningful or because specific messages are needed to populate the control.
  • Progress, because it generally starts at 0%.
  • StatusBar, because there probably isn't any status to show as the GUI is created.
On the other hand, Button and Text account for 49% of the sample (i.e. they are by far the most commonly used controls), and almost never (4%) have Text omitted. However, if the g option is kept, Button controls will nearly always have it. (Only 19% had the g option, probably because the documentation has lots of Buttons, and it tends toward using automatic labels.) Still, 83% of Button and Text controls had options other than v and g.

ListView, Checkbox and Radio controls are the next most common, accounting for around 17% of the sample. 96% had text and 81% had options other than v/g. So the trend seems to be that if you ignore Edit, the most common controls use Text more often than Options. (But then again, Options is application to every control type, whereas Text is not.)
Ragnar wrote:In my opinion, the options are of secondary importance when creating Gui/controls.
What I meant about "I disagree" is that options can be more important than the initial value. Where the method name (or first parameter) identifies the type of control, the options may specify a sub-type, or the nature of the control. The position and other options are also important, and depending on the control or the author's mindset, may be more-so than the text. For controls that take input or raise events, the v and g options are of central importance.
Event Handling

When I started thinking about adding the Name and Event parameters (like just me suggested), it initially seemed odd to put Text between Options and Name. Now I think that was just because I was stuck in an old mindset (v and g being options). I often specify almost the same string for the control's name, g-label and caption, and in such cases I think x%x% y%y% +%style% vDoStuff gDoStuff, Do &Stuff or x%x% y%y% +%style%, Do &Stuff, DoStuff, DoStuff is more natural than Do &Stuff, x%x% y%y% +%style%, DoStuff, DoStuff.

It also got me thinking that maybe controls should all allow automatic event handlers, but based on the control's name (and only if it has one) and the event names, not the control's text. For instance, the ControlName_EventName pattern is pretty common in Microsoft languages, and it's almost the same as what each Gui already has (consistency between the Gui and its controls would be a plus). This would provide convenience for the common cases, while OnEvent() would allow more flexibility. It would encourage script authors to follow this pattern, which would probably help when reading someone else's script. There would be only one mechanism for explicitly setting or removing an event handler (OnEvent), which simplifies the implementation and documentation. It would also mean only one new parameter instead of two.

For Gui events, there would no longer be a +Label/Prefix option; that would become the purpose of Gui.Name, similar to the default labels in v1. Though in that case, it would be inefficient to create the GUI with a default name and then set the name afterward, so a parameter of GuiCreate() would be best (perhaps consistent with Gui.Add()).

Another way was for +/-g to set an event handler for the control's "default" event (usually Click or Change). Because event registration would allow multiple handlers (as with OnMessage, OnExit and OnClipboardChange), -g requires a little more complexity (identifying which handler was the default/+g handler).

As for suppressing events temporarily, I realised that -g .. +gHandler was always less than ideal because it requires specifying the label/function name. Instead, I'm changing Edit.Value/Text to avoid triggering the Change event, making -g somewhat less needed. I also realised that OnEvent(event, handler, -1) .. OnEvent(event, handler, 0) can be used to suppress an event temporarily, by having the handler return a value. (Like OnMessage/OnExit/OnClipboardChange, a negative final parameter means "call it before the others".)

Another point in favour of removing +g and +v is that they will not behave identically to v1, so keeping them around could be confusing.
just me wrote:IMO, the combination [Delete, Add] is sufficient as well as clear.
I agree.

Also, I thought about allowing method chaining by having these methods return the control object. For instance, ListBox.Delete().Add(Items).

I wondered whether it shouldn't be Add(Item) rather than Add(Items). Currently I think it's necessary to write Add([Item]) if Item might contain a pipe/delimiter. And it's inconsistent with ListView.
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

29 Apr 2017, 10:44

Preface
  • My first programming language was COBOL-74 and I used COBOL as my main language until 2014, almost exclusively for HOST applications. So I'm used to write many lines of structured code to solve a problem; each line containing exactly 80 characters. That's why "...this would require an additional line of code" doesn't count for me. But I have to admit that I have no experience with OOP and event-driven programming apart from AHK.
  • IMO, the main goal of the AHK v1 GUI implementation is to collect user input for task automation. When I started using AHK I also used GUIs for this purpose without any problems. As soon as I started to write stand-alone AHK applications, I reached the limits of the existing interface. Some problems can be solved by Control commands. But I always wondered why I had to use them for AHK GUI controls at all. As is, the new interface seems to be new syntax for old features in most cases. I hope, it will turn out to be more.
Options, Text vs Text, Options:

When I started to test the first test built I immediately got the impression that Text, Options would be the 'natural' order. But that might have had two main reasons:
  • I started testing with simple Gui examples.
  • I decided to not use vName and gEventhandler options in general.
The change of the order was surprising me, so I jumped in to question the reasons. After this discussion I cannot decide which order would be the 'better' or 'more natural'. But I can live with both of them.

Name

The names of Guis and GuiControls must be unique (in case of controls per Gui).

In v1 vName belongs to the +/-Options which can be changed via GuiControl at any time. This might be useful to distinguish between different actions based on A_GuiControl (e.g. for 'Start/Stop' buttons). I cannot imagine other useful cases.

As already recommended, the vName option should be replaced in the new GUI interface by an additional optional parameter for GuiCreate() and Gui.AddCtrl(). And because I don't see the need to change the names afterwards, I would like the .Name property to be read-only.

Events

Simple GUI scripts in v1 often need only the GuiClose label to exit the persistent script. This is no longer required in v2 in many cases.

Though some might like the convenience, I recommend to remove the whole concept of default event handlers as well as the gEventhandler option. It's no problem to set/reset event handlers explicitely using the Gui.On... and Ctrl.Event properties; and it improves clarity. The current FuncPrefixOrObj parameter of GuiCreate() should be used only to optionally pass the name of an object holding all event handlers of this Gui. I don't see the need to specify more than one event handler per event/control simultaneously.

Value / Text

Currently, the properties are used as a replacement for both GuiControl and GuiControlGet. I'd prefer they would be used as read-only replacement for GuiControlGet only. GuiControl functions should be replaced by control specific methods, like
Choose() - already exists
SetCaption() - e.g. all controls of class Button.
SetContents() - e.g. Edit, Text, ListBox, etc.
SetFormat() - DateTime
etc.
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

29 Apr 2017, 18:54

just me wrote:After this discussion I cannot decide which order would be the 'better' or 'more natural'.
I agree it's a difficult decision, which is why it's an easy decision. ;) If neither is clearly better or more natural in its own right, then the more familiar one wins.
This might be useful to distinguish between different actions based on A_GuiControl (e.g. for 'Start/Stop' buttons).
That's seemed like a good example at first, but then I considered even in v1, one can just use the text and omit the name/variable, so there's only one thing to toggle. Anyway, I think Name being read-only would be reasonable.
It's no problem to set/reset event handlers explicitely using the Gui.On... and Ctrl.Event properties;
FYI, it's very unlikely that those will remain. The system I am currently testing is:

Code: Select all

GuiOrCtrl.OnEvent(EventName, Handler [, AddRemove])
I am still working out details relating to +/-g, event names and the event handlers' parameters.

It works much the same as OnMessage, only with names rather than numbers. My intention is to also add OnNotify() and OnCommand() to replace the "N" and "Normal" events of Custom controls, but allowing them for all controls, so that scripts never need to handle WM_NOTIFY messages (since it makes debugging a pain, and they sometimes cause deadlocks). Then I might reevaluate which events are supported by OnEvent() vs which ones will require OnNotify().
I don't see the need to specify more than one event handler per event/control simultaneously.
It may add flexibility, with little or no cost. To have individual handlers for each event, we need a variable-sized list to accommodate the different control types without wasting much memory. Since we already have other functions which accept multiple handlers (OnMessage being almost directly equivalent), it's easier to have it function the same, mostly reusing the same code.
I'd prefer they would be used as read-only replacement for GuiControlGet only.
Why?

I will probably change DateTime.Text to return the display text, and add SetFormat() for the format.
... and it improves clarity.
And reduces convenience. I suppose that it also improves error-checking, at least if some is added for methods, or you use functions. Perhaps I will remove the default handlers and we will see how it goes.
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

30 Apr 2017, 03:28

lexikos wrote:
I'd prefer they would be used as read-only replacement for GuiControlGet only.
Why?
Most probably because I confused object properties and plain variables once again. I withdraw my request.
lexikos wrote:My intention is to also add OnNotify() and OnCommand() to replace the "N" and "Normal" events of Custom controls, but allowing them for all controls, so that scripts never need to handle WM_NOTIFY messages (since it makes debugging a pain, and they sometimes cause deadlocks).
Exiting news!

Though rather off-topic: What about Local (force local mode) for functions?
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

30 Apr 2017, 03:41

Some other questions:

1. I'm playing with a concept for 'extended controls'. For me, the easiest way would be to store a reference to the control object within the 'extended object'. Will it prevent the control object from beeing destroyed?

2. Do you intend to implement CtrlObj.Destroy()?
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

30 Apr 2017, 05:03

1. An object cannot be deleted while you hold a reference to it. Windows, however, are automatically destroyed when you their parent window is destroyed. When the window is destroyed, all Win32 resources (GDI brushes, bitmaps, icons, etc.), object references and memory allocations used by the GUI and control objects are freed. Only the objects themselves (one block of heap memory per object) remain while you hold references to them.

The GUI is never destroyed as a direct result of references being released, but it is destroyed automatically if the window is closed when the only reference to the GUI is the one contained by the program's list of GUI objects. The pointer contained by each control (for Ctrl.Gui and internal use) is not counted, and is not accessible after the GUI is destroyed (nor is any other member of the object). In other words, keeping a reference to a control object will never prevent the GUI or control window from being destroyed. If the window is destroyed, you are merely left with a dud object which does nothing but throw an exception when invoked.

2. No. I might look into it in the future.
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

13 May 2017, 01:23

Update: Fixed OnNotify/OnCommand to allow deactivating handlers - AutoHotkey_2.0-a078-107+gaea90d6.zip

Original: AutoHotkey_2.0-a078-106+gf5d8211.zip
I have updated the documentation since the previous build. (Thanks to Ragnar for the previous updates.)

Events

Major changes to event handling.
  • Script subscribes to each specific event by calling OnEvent, and must specify both the event name and the method or function name. Although it's less convenient, the script is easier to understand.
  • Events have sensible names (no mysterious single-letter events).
  • Attempting to register an unsupported event gives a helpful error message.
  • No g-labels.
  • No automatic Gui event handlers (GuiClose, etc.).
  • No specifying AltSubmit to enable additional events.
  • No need to check which event the g-label/handler is being called for.
OnNotify and OnCommand can be used to detect WM_NOTIFY or WM_COMMAND notifications for any control type. These fully replace the "N" and "Normal" events of the Custom control.

Some events which were supported before now aren't, but detecting one is a simple case of passing the appropriate numeric notification code to OnNotify:
  • K: Much less flexible/general than OnMessage(WM_KEYDOWN). If a "KeyDown" event is supported, it should be supported by all control types which accept keyboard focus.
  • D/d: They're only a very small part of what's needed for proper drag-drop support.
  • A: Requires +LV0x40 (obscure) to act any differently to DoubleClick.
  • S/s/M/C: Don't seem useful.
  • MonthCal 1 and 2: Obscure and probably not useful.
  • ListView/TreeView E (user began editing):
    • It's less useful than e.
    • Unlike E, ItemEdit is not raised if the user cancels (since that would probably be undesired most of the time). Raising "begin" without "end" would be inappropriate, and having multiple "end" events (save/cancel) wouldn't seem justified.
    • OnNotify allows the callback to return 1 to prevent editing.
Since registration is always explicit, the following styles are applied automatically:
  • WS_EX_ACCEPTFILES for DropFiles. (This is also removed automatically if all event callbacks are removed.)
  • SS_NOTIFY for Click/DoubleClick of a Text/Pic control.
  • BS_NOTIFY for DoubleClick/Focus/LoseFocus of a Button/CheckBox/Radio control.
Note:
  • Control events no longer have an EventName parameter (Gui events never did).
  • DropFiles puts Ctrl before Files, for consistency with ContextMenu.
  • ItemFocus (ListView) is only raised on focus, not de-focus, since there can only be one focused item at a time (by contrast, v1 had F for focus and f for de-focus).
  • ContextMenu can be registered for each control and/or for the whole Gui.
  • Focus and LoseFocus are supported by more control types.
  • The Gui Size event passes -1 instead of 1 (minimized) and 1 instead of 2 (maximized), for consistency with WinGetMinMax (and because it's easier to remember).
  • DropFiles and ContextMenu now use coordinates relative to the Gui's client area.
  • Link Click passes (Ctrl, ID or Index, HREF) instead of (Ctrl, Index, HREF or ID), and does not automatically execute HREF if a Click callback is registered.
GuiControl Object

DateTime.Text now returns a formatted date/time, and cannot be set. The format can be set with DateTime.SetFormat(format) instead. ShortDate is supported for consistency with FormatTime.

LV/TV.Add/Modify now suppress item-change events, so such events should only be raised by user action or SendMessage.

ComboBox.Value now returns 0 if the text doesn't match an item.

ListBox.Choose()/Value:= now selects all matches (not just the first once) if the control is multi-select.

GuiCtrl.UpdateFont() was replaced with GuiCtrl.SetFont([Options, FontName]).

Choose() now has only one parameter. I think the second parameter existed mainly for parity with Control Choose, which sends notifications. If you need that, use Control Choose (or just call your event callbacks directly). The second parameter may be used for other purposes in future, such as specifying case sensitivity or leading-part vs complete match.

Options

Removed DropFiles option (superfluous/rarely needed).

Removed Prefix option (not relevant anymore).
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: Proposed New GUI API for AutoHotkey v2

13 May 2017, 05:31

lexikos wrote: Although it's less convenient, the script is easier to understand.
In my opinion, easier to understand ⟹ more convienient :thumbup:
In general this seems very good.

I have a small suggestion, for convienence and for ease of understanding (other's) scripts, I suggest to add some property/method for storing relevant data in a gui/control object. I try to motivate with an example, and hope my point is clear enough,

Code: Select all

myGui:= GuiCreate(,"Hello v2")
h1:=LoadPicture("shell32.dll","w64 h64 icon102")
h2:=LoadPicture("shell32.dll","w64 h64 icon103")
myPic:=myGui.AddPic(,"hBitmap:*" h1  )
; This would be convienent:
; myPic.data.pic1:=h1 
; myPic.data.pic1:=h2
; myPic.data.ctr:=0
myPic.OnEvent("Click","f")

myGui.show()

f(ctrl){
	static ctr:=0 ; ctrl.data.ctr
	global h1
	global h2
	ctrl.value:="hBitmap:*" (mod(ctr,2)?h1:h2) ; ctrl.data.pic1 : ctrl.data.pic2
	return ++ctr
}
Now, imagine the case where you have many such controls. Of course there are better options than using global hx in f(), one global or static object would suffice. I think such properties/methods could make it easier to read scripts by others, since you'd immeadiately recognise ctrl.data. Just a thought.

On a side note, the script above seems quite slow, if clicking fast on the image it doesn't respond well, compare to the corresponding script for v1

Code: Select all

h1:=LoadPicture("shell32.dll","w64 h64 icon102")
h2:=LoadPicture("shell32.dll","w64 h64 icon103")
gui, add, pic,gf,% "hBitmap:*" h1
gui,show
f(ctrl){
	static ctr:=0
	global h1
	global h2
	GuiControl, , % ctrl, % "hBitmap:*" (mod(ctr,2)?h1:h2)
	return ++ctr
}
Cheers.
HotKeyIt
Posts: 2364
Joined: 29 Sep 2013, 18:35
Contact:

Re: Proposed New GUI API for AutoHotkey v2

13 May 2017, 07:52

You can use Bind to do that!

Code: Select all

myGui:= GuiCreate(,"Hello v2")
h1:=LoadPicture("shell32.dll","w64 h64 icon102")
h2:=LoadPicture("shell32.dll","w64 h64 icon103")
myPic:=myGui.AddPic(,"hBitmap:*" h1)
myPic.OnEvent("Click",Func("f").Bind(myPic,[h2, h1]))
myGui.OnEvent("Close","Close")
myGui.show()
Return
Close(){
	ExitApp
}
f(ctrl,bitmap){
	static ctr:=0 ; ctrl.data.ctr
	ctrl.value:="hBitmap:*" bitmap[mod(ctr,2)+1]
	return ++ctr
}
EDIT:
removed global vars as these are not used
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Proposed New GUI API for AutoHotkey v2

13 May 2017, 08:52

HotkeyIt that's inconvenient.
Even the bind data for each object part is inconvenient - the way you suggested is even worse since you have to bind data for each callback in each control.
That would mean extra work in both planning and execution and heavy limitations in the language.
We can already see some of the limitations in your example.
Recommends AHK Studio
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: Proposed New GUI API for AutoHotkey v2

13 May 2017, 10:44

HotKeyIt wrote:You can use Bind to do that!
Thank you for your suggestion. My example wasn't very good, I realise, mixing globals and statics it seems like I just need to read the tutorial :oops:. Just looking at that one example, the bind approach is better, however, that is not really what I wanted.
My point is. since the approach with the guis is object oriented, it would be very natural to be able to store relevant stuff with your objects, I don't want to bind these things scattered around in other objects, I might want certain things readily available whenever I work with the objects. And it doesn't have to be in the context of a callback either. Let's say we move a control and want to remeber its previous position, what better place to store that data than within the object itself? In the case of the bitmap handles, maybe they will change later, then we would have to bind a new function object. And so on...
nnnik wrote:That would mean extra work in both planning and execution
Indeed.
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Proposed New GUI API for AutoHotkey v2

13 May 2017, 16:51

Code: Select all

class PictureAlternator {
    ctr := 0
    __new(pics*) {
        this.myGui := GuiCreate(, "Hello v2", this)
        for i in pics
            this[i] := LoadPicture(pics[i]*)
        myPic := this.myGui.AddPic(,"hBitmap:*" this[1])
        myPic.OnEvent("Click", "myPic_Click")
        myPic.OnEvent("DoubleClick", "myPic_Click")
    }
    myPic_Click(myPic) {
        myPic.Value := "hBitmap:*" this[mod(this.ctr++,2)+1]
    }
    Show() {
        this.myGui.Show()
    }
}

myPA := new PictureAlternator(["shell32.dll", "w64 h64 icon102"], ["shell32.dll", "w64 h64 icon103"])
myPA.Show()
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: Proposed New GUI API for AutoHotkey v2

13 May 2017, 17:12

lexikos wrote:myPic.OnEvent("DoubleClick", "myPic_Click")
ty
arcticir
Posts: 693
Joined: 17 Nov 2013, 11:32

Re: Proposed New GUI API for AutoHotkey v2

16 May 2017, 20:09

Compared to the improvement of grammar, I pay more attention to its performance.
I created some flexible instant interface, such as using the GUI to imitate the menu, but its performance is disappointing.
So I am eager to improve it, for example, in giving up using GDI, using more efficient Direct2D.

Thank everyone, the new GUI, exciting.
User avatar
Flipeador
Posts: 1204
Joined: 15 Nov 2014, 21:31
Location: Argentina
Contact:

Re: Proposed New GUI API for AutoHotkey v2

17 May 2017, 22:56

I really like the new GUI API ;) .
One question, Do you intend to add a method to remove controls?.

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 47 guests