Remove Gui.Add("Ctrl", ...) or Gui.AddCtrl(...)?

[lexikos]

Speaking of which, Gui.Add("Ctrl", ...) vs Gui.AddCtrl(...). One of these definitely has to go, and I'm not sure which.

Looking through a few pages of results for "GuiCreate", neither one seems more commonly used than the other. I'm more inclined to remove AddCtrl, if either.

Code size: According to my measurements (using dumpbin.exe and a script), removing AddCtrl reduces x64 code size by 1120 bytes, while removing Add only gives 264 bytes. The Type property could be removed as well, but saving only another 112 bytes. The difference is probably due to the strings for the method names - Gui.Add, GuiControl.Type and GuiControl.__Class all rely on the same array of strings, so it can't be removed either way. (Side note: GuiControl.Type is redundant; it just removes the "Gui." prefix and gives you the exact string to pass to Gui.Add.)

Future use: Add has more potential for future expansion. For example:

• myGui.Add(Scintilla, ...), where Scintilla is a class derived from GuiControl (or implements the right methods).
• myGui.Add(myChildGui, ...) for better integrating nested GUI windows.
• myGui.Add(hwnd, ...) for windows created by other means, such as CreateWindowEx or an external library.

I'm sure there are other considerations, which I will leave to someone else to bring up.

[Helgef]

Future use could be added anyways. It could also be myGui.add ctrl.new(), which would go well together with myGui[name] := ctrl.new() (I know name is a property of ctrl).

I always use myGui.addCtrl, I prefer to add, eg, addButton to my syntax highligter rather than add.

Cheers.

[iseahound]

Both should be kept, there's really no argument for one over the other.

@lexikos why did the ahk v2 size balloon to 3 MB around a76?

[swagfag]

Gui.AddCtrl(...) has the benefit of providing linters/intellisense/highlighters(as helgef says) with more information
i use Gui.Add("Ctrl", ...) for mostly dumb reasons

• its what is used throughout the documentation
• i dont care enough about the highlighter sometimes erroneously painting the occasional .Add() method
• Gui.AddCtrl('', 'Text') would bug me if i had to create controls with default options. rather than switching to Gui.Add("Ctrl", ...) for those particular instances, i just use Gui.Add("Ctrl", ...) all throughout

i dont care if either got removed. i wouldnt care if both were removed either. i dont think both should be kept, though. they pretty much do the same thing exactly, so why keep both around?

---

@Helgef what would it mean to:

Code: Select all

MyBtn1 := Button.New('x0 y0', 'MyButton1')
MyGui.Add(MyBtn1)
MyGui.Add(MyBtn1)
MyOtherGui.Add(MyBtn1)

when is the button created? when u call .New()? when it is attached to a gui? what is its Hwnd? can u attach it only once? do the calls that follow throw or do they clone the control?

---

@iseahound if ure talking about the zip, it simply includes more stuff(x86/x64 exes, docs, bins)

[Helgef]

@swagfag, good questions, maybe it isn't a good idea. I don't know if the actual control could be created without the gui, but the object could ofc. If there is no control .hwnd would throw. Clone/throw, both possible I suppose.

Cheers.

[lexikos]

I think the standard control window classes can be created separately and then inserted into a window using SetParent, however:

• The control's ID depends on how many controls were already in the GUI, as it has to be unique. I'm not sure whether the ID can be changed after creation - there's a GetDlgCtrlID function but no SetDlgCtrlID.
• The style, position and other options may be affected by the GUI. For instance, positioning is affected by DPIScale and in some cases the font. (The desired/unscaled position is not stored; there's only the Win32 window's actual position.)
• The control's font is set based on the GUI's current font, but that's done after creation and could be done by Add either way.

Being heavily OOP, .NET uses an approach where the Control is constructed before adding it to the Window. However, the native Win32 window is not created immediately, and I assume most developers use the form designer anyway.

[Helgef]

Can you make it so one can change one's vote, I clicked the wrong one (ofc )

Sorry.

[nnnik]

If we go with add it should be in the form of:
Gui.add(Button(...), position) or similar.
The argument of a string being more convenient doesn't really hold here. We had v1 which was filled with convenient shorthands.
Those turned out to be nonsense though as the language evolved. (e. g. You only ever want to have a string containing a label name in SetTimer etc..)
Objects are even planned in the recent posts by lexikos.
My most favoured syntax would be:
Gui.add(Gui.Button(...), position)
In this setup the Gui takes up both the role of a container and factory for the controls. Meaning that by simply swapping around gui we can get totally different types of GUIs (e. g. Standard Windows Controls vs. ActiveX IE window.)

[Helgef]

it could be more general: res := obj {p1: v1, p2: v2} -> res := (obj.p1 := v1, obj.p2 := v2, obj).

src
obj {...} looks like concatenation. A natural response to the concatenation of two objects is to create a new one. It could call obj1.__concat(obj2). Then with,

Code: Select all

Object.__concat(right) {
	new := this.new()	; Object.Protototype.__concat would do this.clone()
	for n, v in right.ownprops()
		new.%n% := v
	return new
}

this would be the default response for any class object. So for this topic, it is relevant as aGui.add CtrlClass {...}. Which is generally useful and could reduce the need for option parsing. It also naturally permits CtrlClass DefaultOpts ExtraOpts.

I think this now overlaps with the other topic GuiCreate and Gui.Add parameter order.

Cheers.

I still can't change my vote.

[lexikos]

I still can't change my vote.

Looks like I forgot to enable the option on this topic. It should be enabled now.

[Helgef]

Thanks, I wanted to keep addCtrl, so ofc I click on addCtrl, not realising it says remove addCtrl, typical helgef error .

[jNizM]

In short: I prefer Gui.Add("Control", ...)

Code: Select all

hEdt1 := Gui.Add("Edit", "w400 r5 BackgroundE1BEE7", "Edit 1`nEdit 2`nEdit 3").SetFont("c4A148C")

hEdt2 := Gui.Add("Edit", "w400 r5", "Edit 1`nEdit 2`nEdit 3")
hEdt2.SetFont("c0000FF")
hEdt2.Opt("Background00FFFF")

[HotKeyIt]

Thanks, I wanted to keep addCtrl, so ofc I click on addCtrl, not realising it says remove addCtrl, typical helgef error .

Same happened to me

[just me]

Remove Gui.AddCtrl(...).

[vvhitevvizard]

My most favoured syntax would be:
Gui.add(Gui.Button(...), position)

It could also be myGui.add ctrl.new()

I like these

PS: I voted for Gui.AddCtrl(...) removal. Short variant is preferable, it is better for possible extensions to have additional prefixes, gui.add() used way too frequently.
"keep both" option makes no sense completely.

[Helgef]

I voted for Gui.AddCtrl(...) removal. Short variant is preferable

In my opinion, addCtrl is shorter than add 'Ctrl' .

Spoiler

You also need an extra comma for add 'ctrl' (and space if you like) if you add at least on additional parameter.

Cheers.

[vvhitevvizard]

In my opinion, addCtrl is shorter than add 'Ctrl' .

the latter is more suitable to build controls programmatically. I, for one, would like to have all the .add method's string parameters to be controlled via separate method calls, in addition to the existing syntax. gc.bgcolor(), gc.fontfamily(), gc.fontstyle(), etc.