Proposed New GUI API for AutoHotkey v2

[toralf]

That's the necessary method to implement in order for for ctrlObj in gui to work. See NewEnum() and For-loop.

I misunderstood it, thanks for clarification. I'm good with it.

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.

As with the ctrl.Move() I would propose then to combine them as ctrl.Choose(N, NisString := True). Then you have both posibilities but only a unique function.

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.

Why not make them properties then? Similarly to ctrl.Focused, ctrl.Enabled, ctrl.Visible which can be actions and status depending if used in Set or Get. gui.Hide(), gui.Minimize(), gui.Maximize(), gui.Restore() are not different in that because they do not have parameters.

Yes there is: gui.Control[hwnd].

i forgot about that while working back and forth over the posts.

Since you did not comment on my suggestion to have a script object to iterate over the guis, I assume that that is outside of the inhancements of the GUI commands in v2 which you try to discuss here. The more I think about it that object could basically not only hold all the guis but most likely also all other script properties and methods, e.g. A_IsCompiled, A_AHKVersion and script.Sleep(), etc. I do not think that this is of any benefit any more. So please disregard my proposal. If someone needs to iterate over Guis, he can create an Assosiated Array with gui objects as values.

[fincs]

Why not make them properties then? Similarly to ctrl.Focused, ctrl.Enabled, ctrl.Visible which can be actions and status depending if used in Set or Get. gui.Hide(), gui.Minimize(), gui.Maximize(), gui.Restore() are not different in that because they do not have parameters.

They are state transitions, not properties. A Gui cannot be minimized, maximized and restored at the same time, and thus it does not make sense for them to be properties. The only thing that may be understandable as a property is Hide/Show (=Visible), but since Show has parameters it's best to leave it as it is.

[toralf]

Ok, I understand that they are state transitions and that the state can only a one of them. Introducing Gui.State("Minimized|Maximized|Restored") would be far away from v1, and I understand that you would like to keep it close to v1. To have it closer to v1 I would propose Gui.Minimized, Gui.Maximized, Gui.Restored. The state (Get, property) Minimized, Maximized and Restored are mutually exclusive. And each of these 3 actions (set, state change) changes the state of the gui and alters the value of all three properties. Overall the symmitry to the controls object would ease IMHO the learning curve.
Since Gui.Show([Options]) does also support the option "Hide" the action Gui.Hide() would not be needed necessarily. Overall my proposal would be that Gui.Show("Maximize") and Gui.Maximized := True would both maximize the GUI. And a If Gui.Maximized would simplify to get to the current state and do actions accordingly.

PS: I use 'Restored' with the meaning: visible but not maximized or minimized, Any other word that represents this state is fine with me, but this is used for v1.

[toralf]

Am i Right to assume that a GUI.Submit() would not be required? Meaning that every control object always has the updated value all the time.

Edit: maybe it is still needed: because of starting new threads and concurrent nature of GUIs it might be beneficial to give the user the ability to define the snapshot of data.
E.g. If one thread takes long to finish another might be started. Either each carries it's own snapshot of data (automatically or by collecting the data at the start of the thread) or the data might get changed/updated in the middle of the thread.

[fincs]

Yup, Gui.Submit() would be gone. Also, AHK threads do not work the way you described - threads are never simultaneously executed.

[toralf]

I do not understand. A GUI with 2 buttons could start two threads if each is long enough. Each thread gets it share of CPU time/slice. Thus they are kind of parallel , aren't they?

[guest3456]

http://www.ahkscript.org/docs/misc/Threads.htm

[joedf]

I like this idea. I haven't tried AFC yet, but I will soon

[lexikos]

Also, AHK threads do not work the way you described - threads are never simultaneously executed.

Isn't that irrelevant? If one GUI thread takes too long, another can be started and interrupt the first. They won't be executed simultaneously, but when the second thread finishes the first will resume and may see the wrong values. Even if there's only one thread, if it takes too long the user might have opportunity to change the values of some controls.

If that's an issue, the user can just retrieve the values they need at the start of the thread (i.e. before doing anything lengthy).

[joedf]

@Lexikos Hmm, I tend to Disable the GUI in that case. Is it bad practice? Or is that ok?

[lexikos]

Of course it's okay. Solves the problem, doesn't it?

[toralf]

It depends on what you try to achieve.

[joedf]

@Lexikos true, haha thx
@toralf Please elaborate

[toralf]

My comment was on:

... I tend to Disable the GUI in that case. Is it bad practice? Or is that ok?

It is neither bad nor good practice IMHO, it depends on what you want to achieve with the GUI.

[joedf]

I see...

[evilC]

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.

Are you proposing here to allow all option strings to be associative arrays?

eg would something like GuiCreate("myTitle", {x: 11, y: 22, w: 23, h: 45, Resize: false, Border: false, Parent: myMainGui.hwnd }, FuncPrefixOrObj) be valid?

If so, how would passing of hex values for window styles (eg 0x00100000 AKA WS_HSCROLL) work? WindowStyle: 0x00100000? 0x00100000: true ?

This would be a really cool change IMHO - it would be much easier to work with class based GUIs if we didn't have to parse a string to manipulate the passed options.

And do you have any plans to port AFC to v2 once these changes are made?

[fincs]

Are you proposing here to allow all option strings to be associative arrays?

No, I'm only proposing to accept associative arrays instead of flexilists in some cases where it's more convenient (e.g. the Move method in controls). General control/Gui options still use flexilists (and the Opt/Options method for changing them), although I plan on adding some property sugar (in order to allow things like gui.Owner := anotherGui or ctrl.Border := true).

And do you have any plans to port AFC to v2 once these changes are made?

No. AFC was created to OOPize the Gui commands in v1.1. If v2 has built-in OOP Gui, there's no need for AFC.

With that said - over the past days I have successfully implemented this OOP Gui proposal in v2 (with some minor design changes). Expect test binaries soon - I want feedback so that the interface is as convenient/intuitive as possible before Lexikos considers merging it into the v2-alpha branch.

[toralf]

I am all up for it. waiting.

[guest3456]

With that said - over the past days I have successfully implemented this OOP Gui proposal in v2 (with some minor design changes).

Nice work.

Expect test binaries soon - I want feedback so that the interface is as convenient/intuitive as possible before Lexikos considers merging it into the v2-alpha branch.

I think this note about the syntax/interface is the most important. When you are ready with your proof of concept, please document the usage examples

[evilC]

Ah, I had missed the example code, yes that becomes clear now.

However, I still much prefer AFC's way of doing things, this to me just seems like a step in the opposite direction.

Code: Select all

gui := GuiCreate("Image Viewer", "Resize", "MyGui_")
gui.AddButton("&Load New Image", "Default")
[...]
MyGui_ButtonLoadNewImage()
{
	[...]
}

The whole MyGui_ButtonLoadNewImage being made up of Gui name (MyGui_) plus button name ("&Load New Image" = LoadNewImage) - Yuck! If you change the label, you have to change the function name?

As opposed to the loveliness that is AFC:

Code: Select all

class MyMainWindow extends CWindow
{
	__New()
	{
		base.__New("Image Viewer", "+Resize")
		new CCtrlButton(this, "Load New Image").OnEvent := this.ButtonLoadNewImage
		this.Show()
	}

	ButtonLoadNewImage()
	{
		[...]
	}
}

Now I can understand why it is kept that way in vanilla AHK, to keep people from having to learn classes when implementing UIs, but I still would love to see AFC for v2