Code: Select all
GuiObj := GuiFromHwnd(Hwnd, true) ; A_Gui
The hwnd parameter will be needed much more frequently than in v1.1. Wouldn't it make sense to change the parameter order?
Code: Select all
GuiObj := GuiFromHwnd(Hwnd, true) ; A_Gui
Code: Select all
MyGui := GuiCreate([Options, Title := A_ScriptName, FuncPrefixOrObj := "Gui"])
MyGui.Add(Ctrl [, Options, Text])
MyGui.AddCtrl([Options, Text])
Why did you do that? In my opinion, the options are of secondary importance when creating Gui/controls. Additionally it's somewhat easier to read, especially for beginners (for example, GuiCreate("Title of Window") vs GuiCreate(, "Title of Window"))Lexikos wrote:Swapped Options with Text/Title for GuiCreate() and Gui.Add(), putting Options first and Text/Title second, as in v1.
fincs wrote:By the way, I am not sure if reversing the parameter order in AddCtrl() was a good idea (i.e. Options, Value vs Value, Options).
https://autohotkey.com/boards/viewtopic ... 866#p38866
lexikos wrote:Gui.AddCtrl(Text, Options) vs Gui Add, Ctrl, Options, Text is bound to cause confusion with users familiar with the old order. Since even fincs expressed doubt about it, I'd guess it should be swapped back. Perhaps Options would be omitted more often than Text, but usually there's at least one option. Another point is aesthetics (which can affect readability); with several controls on a Gui, the options parameters often line up (i.e. when they aren't preceded by text of varying length).
https://autohotkey.com/boards/viewtopic ... 57#p138957
fincs wrote:The main reason this was changed was that the syntax for specifying just the text and not the option (e.g. btn := gui.AddButton("", "Text") or gui.AddLabel,, Text) contained that extra empty parameter that looked ugly. I had always thought that the Text parameter was more used than the Options and thus it should be promoted to be the first parameter. However, it is indeed true that existing users would be confused by the change, so ultimately perhaps it should be changed back in gui.AddCtrl. But again, if GuiCreate keeps Title first, it would be inconsistent with it.
(I'm aware just me's request for additional parameters showed Text before Options, but he did not mention it specifically.)joedf wrote:I agree with swapping addCrtl.
Ragnar wrote:In my opinion, the options are of secondary importance when creating Gui/controls.
I disagree. GUIs intended for collecting input often have no initial values. In my experience, the value is omitted more often than the options.just me wrote:Very most of the controls will get a value when created.
Are you saying that Edit controls (for example) should not use the Value property? I don't see why. I think it is counter-intuitive for Edit.Value to return 0. Also, DateTime and MonthCal return a string (of digits).just me wrote:If used in this manner I propose to use Value only for numeric values like indices or states.
Perhaps when the options are omitted; otherwise, I disagree.Additionally it's somewhat easier to read, especially for beginners
I assume you mean this:just me wrote:BTW, is there or do you intend to implement a replacement for the radio group variable of v1?
As far as I can tell by testing in v1 (I don't have the source code at hand), it only applies to Submit. It still applies to Submit in the same way, only with variables being replaced by array elements.The radio button's associated output variable (if any) receives the number 1 for "on" and 0 for "off". However, if only one button in a radio group has a variable, that variable will instead receive the number of the currently selected button: 1 is the first radio button (according to original creation order), 2 is the second, and so on. If there is no button selected, 0 is stored.
Code: Select all
Gui, Add, StatusBar, vTest -Theme BackgroundGreen
Gui, +Resize +MinSize320x200
Gui, Font, s8, Arial
Code: Select all
C := MyGui.AddStatusBar("vTest -Theme BackgroundGreen") ; this works ...
; ??????????????? Whats to do here?
C.Resize := 1 ; doesn't work
C.Options("+Resize +MinSize320x200") ; doesn't work - esp. MinSize is said to be an invalid option ...
C.Font("s8, Arial") ; doesn't work ...
...
Code: Select all
MyGui := GuiCreate("+Resize +MinSize320x200", "Test") ; current test built 2.0-a078-69+gde353c8
MyGui.SetFont("s8", "Arial")
MySB := MyGui.AddStatusBar("vTest -Theme BackgroundGreen", "Initial value") ; this works ...
MyGui.Show()
Code: Select all
MyGui := GuiCreate()
MyGui.Opt("+Resize +MinSize320x200")
MyGui.SetFont("s8", "Arial")
MySB := MyGui.AddStatusBar("vTest -Theme BackgroundGreen", "Initial value") ; this works ...
MyGui.Show()
I didn't expect it would be that easy, sorry.lexikos wrote:I assume you mean this: ... It still applies to Submit in the same way, ...
I disagree, Button, Checkbox, Radio, Text, Picture, ListBox, DDL, ComboBox controls without initial contents / captions?lexikos wrote:I disagree. GUIs intended for collecting input often have no initial values. In my experience, the value is omitted more often than the options.just me wrote:Very most of the controls will get a value when created.
Yes. The 'Value' of an Edit control is its 'Text'. And it's redundant to return the 'value' of a large Edit control twice in Value as well as in Text.Are you saying that Edit controls (for example) should not use the Value property?
Because I didn't expect that you would actually do it based on only 2 pros. I think that the main reason for the change is backward compatibility, which isn't the objective of v2. I don't prefer this order, but I can live with it.Why did no one object when it was first brought up, before the change was made?
You can also take a look at the v2 docs, which already contain the new GUI API: https://github.com/Lexikos/AutoHotkey_L-Docs/tree/v2hoppfrosch wrote:Thanks, @just me - I have read the OP, but it seems I missed the wood for the trees ...
My opinion was that options are omitted more rarely than text, not that text is omitted often.just me wrote:I disagree, Button, Checkbox, Radio, Text, Picture, ListBox, DDL, ComboBox controls without initial contents / captions?
So tell me why Value should not return the control's value.Yes. The 'Value' of an Edit control is its 'Text'.
It is not redundant if Value and Text perform different functions. A script author may have a reason not to perform EOL translation, such as for performance when the text is already in the right format, or to preserve the content if that is more important than it displaying as multiple lines.And it's redundant to return the 'value' of a large Edit control twice in Value as well as in Text.
I said "I'd guess it should be swapped back" and then no one objected. Why would I not follow through?Because I didn't expect that you would actually do it based on only 2 pros.
Another point I considered (which I don't think has been mentioned) is that LV_Add/LV.Add() puts options first. I think users generally write LV_Add("", ...) rather than LV_Add(, ...) (of course, the latter wasn't always possible).fincs wrote:On the other hand, I realized that for some control types (mostly input related) such as Edit, the Text parameter won't really be used as much as the Options parameter; so we would be back to dealing with the same problem. Users would be irritated that Gui, Add, Edit, vMyEdit would become gui.AddEdit,, vMyEdit (or gui.AddEdit("", "vMyEdit") for that matter). Ultimately I don't know what benefits most users.
Familiarity and backward compatibility aren't the same thing. It is not backward compatible, nor did I bring up backward compatibility.I think that the main reason for the change is backward compatibility,
Code: Select all
WM_LBUTTONDOWN(W, L, M, H) {
ThisGui := GuiFromHwnd(H, 1)
If (ThisCtl := GuiCtrlFromHwnd(H))
CtlType := " - " . ThisCtl.Type
ToolTip(ThisGui.Name . CtlType)
}
Return to “AutoHotkey Development”
Users browsing this forum: No registered users and 51 guests