For argument's sake, I would say that these functions have different usage, so the familiar naming could be a hindrance rather than a help. These are functions used to register (add) callback functions, whereas OnClose and family are both name suffixes and properties to be assigned. It's similar to how in (older) v1 OnMessage accepted a function, OnExit accepted a label, and OnClipboardChange was a label.fincs wrote:This was inspired by OnExit, OnClipboardChange and OnMessage.
I had idly considered whether it was worth implementing a method of registering events similar to the On..() functions; i.e. allowing multiple handlers for each event. It can be added later if someone decided it would be a valuable feature (even if the same name is used, since Gui.OnClose(x) raises an error), but then Gui.OnClose := x would be twice redundant. Maybe one of the existing implementations (e.g. from OnMessage) can be reused for this.
Perhaps the default prefix should be "On" when an event sink object is specified. I suppose "Gui" works too.These are very generic words that could cause trouble if the Gui handler class contains a similarly named member.
That was the idea, unless they are replaced with something else.Also, I suppose the names of the event getters/setters (e.g. gui.OnClose := Func("somefunc").Bind("Close")) will keep the On prefix.
Prefix/g was just to allow an object and a prefix to be combined. I don't think it has any bearing on whether GUI events and control events share a prefix, unless you consider more specific alternatives, like "GuiPrefix" and "CtrlPrefix". I think the character "g" only makes sense if it's to be combined with the control's "g" option (i.e. a shared prefix, or a prefix for all controls but not GUI events).... and if the beforementioned Prefix/g option were introduced for (non-control) Gui event handlers, there would be no need whatsoever for a Gui event prefix.
I think that's worth considering in combination with a different mechanism to register event handlers; e.g. an OnEvent or addEventListener-like method instead of several event properties.In fact there were so many possible events that a certain group of them have to be explicitly enabled with the AltSubmit option. Perhaps this should be broken up in smaller, single-purpose handlers just like the set of event handlers that Gui themselves have.
But then we'd have to consider whether it's worth keeping the single-handler-for-all-events method ("g" option) as well, to facilitate the transfer from v1 (or any other reason, like simplifying code reuse across multiple events). If not, I suppose that would supersede the following question:
Do you think there's value in keeping strict "Event, EventInfo, ErrorLevel" parameter ordering for all control types? For instance, Link controls pass "Normal", LinkIndex, HrefOrID where probably only HrefOrID is needed. ListBox controls might not care about click vs double-click (Event), but probably want the row number (EventInfo).
I see your point. I tend to omit the initial comma, so being required to write double-comma rather than nothing would be a slight irritation. On the other hand, Gui Add, Text,, Text always required double-comma.gui.AddLabel,, Text
One may also consider MsgBox, InputBox and TrayTip, which all use "Text, Title, Options" as of v2.0-a078.But again, if GuiCreate keeps Title first, it would be inconsistent with it.