MsgBox, InputBox, TrayTip

Discuss the future of the AutoHotkey language
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

MsgBox, InputBox, TrayTip

14 Oct 2016, 18:10

I plan to make the following changes:
  • Remove MsgBox smart comma handling.
  • Remove A_MsgBoxResult.
  • Change MsgBox usage as below (and InputBox and TrayTip further below).

Code: Select all

          MsgBox Text [, Title, Options, ByRef Result]
Result := MsgBox(Text [, Title, Options, ByRef Result])
I think that using an output parameter is more natural than having a built-in variable just for this function's return value. The output parameter could be exclusive to command mode, but it's just as easy (same amount of code) to have it in both modes.

Most (but not all) commands/functions with return values put the OutputVar first and omit it in expression mode, but doing that for MsgBox would mean writing MsgBox,, quite often.

Options would be as it is now, or optionally a space-delimited list of more memorable string options. This is the part I'm not sure about - what string values to use. Currently I'm thinking this:

Code: Select all

OKCancel
AbortRetryIgnore
YesNoCancel
YesNo
RetryCancel
CancelTryAgainContinue

Iconx
Icon?
Icon!
Iconi
They should be self-explanatory. I also considered contractions like y/n, possibly altering the return value in that case to allow brevity when comparing the result - i.e. MsgBox(Text,, "y/n") = "y" vs MsgBox(Text,, "YesNo") = "Yes". However, Cancel/Try Again/Continue throws a spanner in the works (two 'C's). 'C' for Cancel is obvious with OK/Cancel, but Windows actually underlines Continue. (There's no mnemonic for Cancel - it's tied to Escape.)

For the icons, I think a single character resembling the icon is more memorable and convenient than a word like Stop/Error/Hand. I considered not requiring "Icon", but x should be reserved for possible use positioning the MsgBox.

I think the other options are less frequently used and can stay as numbers. A string of options could also include numeric options, combined or individually (just as the Gui command allows style options).

InputBox and TrayTip would have consistent parameter ordering:

Code: Select all

InputBox, OutputVar [, Text, Title, Options, Default]
TrayTip [, Text, Title, Options]
Text comes first, as Title is often omitted. TrayTip's Seconds parameter may be removed completely (since it only works on XP) or merged into Options as a string.

This also makes TrayTip consistent with ToolTip and fixes the problem of TrayTip Some text not actually showing a TrayTip (it should be TrayTip Title, Some text in v1).
just me
Posts: 9423
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: MsgBox, InputBox, TrayTip

15 Oct 2016, 03:59

Code: Select all

          MsgBox Text [, Title, Options, ByRef Result]
Result := MsgBox(Text [, Title, Options, ByRef Result])
Both are looking kinda strange for me. For consistency, I'd prefer

Code: Select all

          MsgBox, [Result], Text [, Title, Options]
Result := MsgBox(Text [, Title, Options)
String options:
Sounds good, contractions also: o/c, a/r/i, y/n/c, y/n, r/c, c/t/c. But IMO, the return value shouldn't be abbreviated.

Icon should be required.
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: MsgBox, InputBox, TrayTip

15 Oct 2016, 06:24

I'd prefer to be required to use expression syntax than to be required to write double-comma the majority of times that I call MsgBox.

Although v2 doesn't aim to be compatible with v1, keeping Text as the first parameter would keep compatibility in many cases (where the single-parameter mode was used with text that does not contain commas). More importantly, it would be more familiar and would not require as much "retraining" of habits.

Run is similar, in that its output var is often not needed so is put last. But unlike Run, MsgBox's result is completely useless in common cases (i.e. when Options is omitted).

With Result last, the variable name would typically be written immediately after the option which defines what possible values it can receive.

I suppose that the ideal usage depends on whether you just want to show a message or to get input from the user. One idea is to split MsgBox into two functions, or have InputBox show a message box if given certain options (however, each has options not applicable to the other).

Code: Select all

; Simple proof of concept. Works on v2.0-a076.

; Just want to show a message?
MsgDlg This is just a message.

; Want yes/no input?
InputDlg yesOrNo, Are you sure you want to click the button?,, YesNo, 2

; Want other input?
InputDlg whatever, What kind of input?

MsgDlg(Text:="", Title:="", Options:="") {
    MsgBox(Options, Title, Text)
}

InputDlg(Text:="", Title:="", Options:="", Default:="") {
    static Buttons := { OKCancel: 1, AbortRetryIgnore: 2, YesNoCancel: 3
        , YesNo: 4, RetryCancel: 5, CancelTryAgainContinue: 6 }
    static Defaults := { 2: 0x100, 3: 0x200 }
    if Buttons[Options] {
        MsgBox(Buttons[Options] | (Defaults[Default] || 0), Title, Text)
        return A_MsgBoxResult
    }
    return InputBox(Title, Text, Options, Default)
}
JavaScript has alert(), confirm() and prompt().
just me
Posts: 9423
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: MsgBox, InputBox, TrayTip

15 Oct 2016, 06:39

I'm quite sure i'd never use the command when Result := MsgBox(Text [, Title, Options, ByRef Result]) is implemented. ;)
Coco
Posts: 771
Joined: 29 Sep 2013, 20:37
Contact:

Re: MsgBox, InputBox, TrayTip

15 Oct 2016, 13:27

Looks good to me. I prefer the contractions for the options.
Drugoy
Posts: 48
Joined: 11 Jun 2016, 07:37
Contact:

Re: MsgBox, InputBox, TrayTip

16 Oct 2016, 18:51

lexikos wrote:JavaScript has alert(), confirm() and prompt().
I'd like to see those in AHKv2 as well.
lexikos wrote:

Code: Select all

          MsgBox Text [, Title, Options, ByRef Result]
Result := MsgBox(Text [, Title, Options, ByRef Result])
That is acceptable.
lexikos wrote:Options would be as it is now, or optionally a space-delimited list of more memorable string options.
Would be nice if you would also add support of getting the list of options from arrays as well. I guess it would be hard to add and it won't bring big amount of comfort, so I'd rate this feature request quite lowly.
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: MsgBox, InputBox, TrayTip

16 Oct 2016, 22:15

Drugoy wrote: Would be nice if you would also add support of getting the list of options from arrays as well.
Why?
Drugoy
Posts: 48
Joined: 11 Jun 2016, 07:37
Contact:

Re: MsgBox, InputBox, TrayTip

17 Oct 2016, 07:13

Honestly, I don't know. I just feel like for better support of dynamic GUIs AHK should better support getting options from a variable (that contains a string) or an array (since I figured out how to work with arrays and objects - I now use them almost everywhere to store lists instead of using plain str variables for that).
I don't insist on that idea. It would be nice to have, but it's not really important.
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: MsgBox, InputBox, TrayTip

17 Oct 2016, 23:32

How could it possibly "support getting options from a variable (that contains a string)" better than it already does? If you want to pass a variable, just do it.

Well, okay, the MsgBox command's "smart comma handling" interferes with that, but as I said, I'm removing it. And passing a variable using function syntax in v2 is dead simple. In v1.1, you can use MsgBox % options,, Text.
egocarib
Posts: 100
Joined: 21 May 2015, 18:21

Re: MsgBox, InputBox, TrayTip

21 Oct 2016, 16:34

I really like this. Parameters are in the order of most often used, which is great. I will be glad to be done with the idiosyncrasy of A_MsgBoxResult.

Code: Select all

Result := MsgBox(Text [, Title, Options, ByRef Result])
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: MsgBox, InputBox, TrayTip

19 Mar 2017, 04:28

I've implemented the changes in v2.0-a078-e25d96b, mostly as I originally planned.

I also added an option to specify the owner of the MsgBox. This overrides Gui +OwnDialogs and can be used with windows belonging to other programs.
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: MsgBox, InputBox, TrayTip

19 Mar 2017, 08:42

Can you link me to the part in the v1 code that contained the 'smart comma handling' ? I'm curious how this worked in the past

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: MsgBox, InputBox, TrayTip

19 Mar 2017, 21:30

The current v1.1 implementation is in script.cpp, line 4653. The implementation was different prior to v1.1.06.00.
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: MsgBox, InputBox, TrayTip

19 Mar 2017, 21:33

ok thanks


Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 35 guests