GUI suggestions

[fischgeek]

Firstly, I have "brushed" up on the v2 docs and other posts here in this forum and I have to say I'm pretty excited for v2. I was directed here by fincs and I hope my post will not be scrutinized too terribly much.

That being said, I'd like to see the following changes when it comes to guis (specifically controls)
Text be changed to Label (Gui, Add, Label)
Edit be changed to TextBox (Gui, Add, TextBox)
Allowing a background color on a Label would be great (natively)
Implement margins and padding for individual controls (I think this would allow for a more customized layout)

[lexikos]

Your suggestions don't seem to be specific to fincs' proposed GUI API (this topic [Edit: these posts have since been moved]).

Text -> Label: sounds good. Even I've confused Text with Edit/TextBox.
Edit is the Windows class name, so ClassNN will always be Edit1 (or similar) regardless of what the Gui command calls it. Therefore, I'm in favour of leaving it as is.
Background color: falls outside the scope of v2, I think.
Margins: can't you just use Gui Margin before/after creating the control and/or use y+10 or similar in the options?

[fischgeek]

Your suggestions don't seem to be specific to fincs' proposed GUI API (this topic).

I apologize, I thought that this was where I could suggest stuff related to GUIs. Please feel free to move it if you think it's better somewhere else.

Text -> Label: sounds good. Even I've confused Text with Edit/TextBox.

Sweet.

Edit is the Windows class name, so ClassNN will always be Edit1 (or similar) regardless of what the Gui command calls it.

True. However, regardless of what a language a windows app is built in, the ClassNN name is Edit1 (like you stated). But, if you try to build a Windows Forms project or WPF, it's TextBox.

Background color: falls outside the scope of v2, I think.

How so? And, how come?

Margins: can't you just use Gui Margin before/after creating the control and/or use y+10 or similar in the options?

It would be really annoying to have two lines of code for each control that I want to margin around. Being able to specify a control's margins (to me) would be extremely beneficial. But, I'm just one person with one opinion.

Thanks for the reply.

[lexikos]

You can suggest stuff wherever you want, but if I wasn't interested in discussing fincs' proposal I would have missed your suggestions.

Scope of v2: Does it impact script compatibility? If so, maybe I'm wrong.

Margins: What are you proposing? Using y+10 in the options when creating the control effectively gives it a 10-pixel margin, and does not require an extra line of code.

We're not trying to use WPF. Gui and ControlGet etc. are both in AutoHotkey. AutoHotkey scripts will often need to deal with "Edit1" and similar, sometimes even when referring to their own controls. Although beside the point, I'm fairly certain that .NET and therefore WPF controls do not use plain window classes, so would not have just "Edit1" as a ClassNN.

[fischgeek]

You can suggest stuff wherever you want, but if I wasn't interested in discussing fincs' proposal I would have missed your suggestions.

If I want you to see it, where should it go? v2-thoughts Discussion?

Scope of v2: Does it impact script compatibility? If so, maybe I'm wrong.

I didn't think v2 was worried about compatibility? Or am I missing what you're saying here?

Margins: What are you proposing? Using y+10 in the options when creating the control effectively gives it a 10-pixel margin, and does not require an extra line of code.

Okay. I understand that, but I was more so speaking towards left and right margins (x). I (at some point) was getting frustrated with layout complications. It just would be nice to not have to worry about Sections and what not. In this example for instance I had to create a section and manually adjust the x coords (in conjunction with xs) to achieve the layout I wanted.

Spoiler

Code: Select all

Gui, Add, Edit, Section
Gui, Add, Edit, xs xp+20
Gui, Add, Edit, xs xp-20
Gui, Show
return

GuiClose:
ExitApp

It would be nice if I were able to say Margin-Left20 or (or something similar) and have the control be bumped over 20px while retaining its original x coord so that the next control would fall below it (less 20px). I may be way off base here as far as requests go, and furthermore I may be the only one here who thinks this would be beneficial. But, thanks for listening anyway.

We're not trying to use WPF. Gui and ControlGet etc. are both in AutoHotkey. AutoHotkey scripts will often need to deal with "Edit1" and similar, sometimes even when referring to their own controls.

So, it's more involved than I'm thinking of just changing "Edit" to "TextBox" is what you're saying?

I'm fairly certain that .NET and therefore WPF controls do not use plain window classes, so would not have just "Edit1" as a ClassNN.

Damn. You're right.

Spoiler

Again, thanks for your time.

[lexikos]

If I want you to see it, where should it go? v2-thoughts Discussion?

There's a whole forum for v2 topics. I've split the posts discussing your suggestions into this new thread. Feel free to edit the thread title.

Scope of v2: Does it impact script compatibility? If so, maybe I'm wrong.

I didn't think v2 was worried about compatibility? Or am I missing what you're saying here?

v2 is is very much concerned with compatibility - specifically, breaking it. If it doesn't impact script compatibility, it can be implemented in v1.x or v2.x or any other version.

but I was more so speaking towards left and right margins (x).

x+10? Your suggestion doesn't seem intuitive to me.

I think your use of 'Section' is really just to work around the fact that when you do xp+, it doesn't put the control on the next row. This seems to have the same end result, but solves the problem more directly:

Code: Select all

Gui, Add, Edit
Gui, Add, Edit, y+10 xp+20
Gui, Add, Edit, y+10 xp-20
Gui, Show

...or you could do this:

Code: Select all

Gui, Add, Edit
Gui, Add, Edit, xm+20
Gui, Add, Edit, xm

So, it's more involved than I'm thinking of just changing "Edit" to "TextBox" is what you're saying?

No, I'm saying that whatever name you have to use to create the control, it's still an Edit control, and you're still going to have to refer to it as such with the Control commands, SendMessage, etc. What benefit do we really get from renaming it? AutoHotkey isn't really aimed at programmers, the main group that might know it as a "TextBox".

Renaming Text to Label is different, because users type Text into an Edit control... Maybe I'm mistaken about this one, and average users have no problem with the current name. Maybe I do only because I've used frameworks where "Text" or "TextBox" refers to an Edit control.

Still, I think Label and Edit are clearer; but one is a text label and one is for editing text. On that note, a Label control is a box containing text; in other words, a text box.

[tank]

Still, I think Label and Edit are clearer; but one is a text label and one is for editing text. On that note, a Label control is a box containing text; in other words, a text box.

makes 2 of us. its one of the few places that i think ahk is more noob friendly for gui

Maybe we should also have name text value and caption attributes as well to add to the confusion

There is a fine line between "noob friendly" and "new to ahk friendly". I tend to side with "noob friendly"

[fischgeek]

I don't disagree with either of you. I'm merely trying to find some consistency amongst languages. So new programmers who came to ahk for an introduction into the programming world. (like I did) wouldn't get confused with the different control titles. However, having said that it's really not that big of a deal. If anything I'd just like to see Text changed to Label.

Thanks again.

Maybe we should also have name text value and caption attributes as well to add to the confusion

lol. You're mocking me, aren't you? -- still that wouldn't be the worst thing in the world. I have often thought it would be pretty awesome to have text and value (at least for DDLs). Put that one on the list lexikos!

[toralf]

The word label is also used in GUI commands in g-label. That could cause confusion

[fischgeek]

Valid point. I don't think it would be that bad though. I've always tried not to use the term "label" when talking about the "g" option. I just say "g" stands for "go to" this subroutine. I personally think that if the change from Text to Label is approved and implemented, the documentation needs to be changed for g-label explanations. It should say something like what I mentioned earlier.

Again, just my thoughts.

[tank]

ok i cant really argue about that. but then i always thought it strange to use g for events and v for name.... I dont think there is a programmer friendly way to go here use g-soubroutine..?
I think the problem is that they are defined in a way that many will still think of them as labels. because every goto gosub command in every language i know does.
but the gui item then i cant think of anything more fitting that label except caption. the problem here is ambiguity with the no caption option.

I dont know how we get rid of all ambiguity

[guest3456]

can change the docs from g-label to g-sub ? dunno.

although i don't think Gui, Add, Text|Edit is all that confusing for me anyway

you could change it to Static because thats the class of those controls, but i think "Static" is even more confusing though

[fischgeek]

"Label" would fall more in line with other languages. And to tank's point we can't completely get rid of ambiguity. In the end the programmer just has to learn and become familiar with it.

Maybe "e" would be a good fit. (event)?

[lexikos]

If fincs has his way there probably won't be a g-label. Even if he doesn't, I had considered changing it to make more sense when functions are allowed in place of subroutines. (But to what?)

Anyway, "a label control/a label on the GUI" and "a control's g-label" are quite clearly different. Like "a text control" and "a control's text".

g is for gosub, BTW.

[fischgeek]

What about just appending predefined labels on each control's variable declaration? So, if I had a control with a variable declaration of "vMyButton" I would have options for predefined events with the variable as the prefix. So, MyButton would have a click event of MyButton_Click. Or on some controls (like a ListView) could have multiple events: MyListView_DoubleClick.

The programmer would then just implement that subroutine/function and any code to go along with it.

[guest3456]

What about just appending predefined labels on each control's variable declaration? So, if I had a control with a variable declaration of "vMyButton" I would have options for predefined events with the variable as the prefix. So, MyButton would have a click event of MyButton_Click. Or on some controls (like a ListView) could have multiple events: MyListView_DoubleClick.

The programmer would then just implement that subroutine/function and any code to go along with it.

not a bad idea..

[joedf]

Intuitive... But might lead to more bulky code no?

[fischgeek]

Intuitive... But might lead to more bulky code no?

How so? You wouldn't have to include the predefined event(s) unless you wanted to; they would just be available to you. It would technically be less code since you wouldn't have to define "g-labels".

[tank]

it would certainly go along with the style of AHK syntax to date

[guest3456]

Keep in mind, AHK already does this , except instead of using the variable name, it uses the text of the button appended to the word "Button" to name the label.

Code: Select all

gui, add, button,, Press Me
gui, show, w100 h100
return

ButtonPressMe:
   msgbox, hello world
return

I do think using %VariableName%_Click: is preferable over Button%ButtonText%: though.

and I guess you're proposing doing away with A_GuiEvent and instead just have different automatic subs for each Click/DoubleClick/etc event