Space after function causes it to fail

[Industry]

I was updating a script from v1 to v2 and using the WinGetMinMax ("A") function kept giving an error message

Code: Select all

Error: Expected a String but got a Func.

That's weird, I thought, only integers can be output.

After some testing I realized this works as expected WinGetMinMax("A"). The difference? The space before the parenthesis.

Why does that make a difference? Shouldn't the interpreter understand both the same way?

[boiler]

Why does that make a difference? Shouldn't the interpreter understand both the same way?

No. Why should the interpreter understand something that doesn't meet the documentation? You haven't shown your full script line that would cause that error, but I imagine it was something like this:

Code: Select all

MsgBox WinGetMinMax ("A")

It was trying to concatenate the two things, which is just a function name and a literal string, not a function with the literal string passed to it.

If it could allow either, how would the following be correctly interpreted?

Code: Select all

MsgBox ("Body text.", "Title")

With the space, it's an expression being sent as the first parameter because it is using the "command" format where a space can be used without parentheses between the function and the parameter list. And that expression has two strings separated by a comma, so the returned value is the last statement, so it puts "Title" in for the body text of the MsgBox and does nothing with the "Body text". But when done correctly:

Code: Select all

MsgBox("Body text.", "Title")

Then the parameters are in their correct places because it's a correct function call format, and the title and the body are both shown. To use the command format correctly, you wouldn't group them into the same expression, but it would be like this:

Code: Select all

MsgBox "Body text.", "Title"

...which also produces the expected output.

Moving this thread from "Bug Reports" to "Ask for Help (v2)".

[boiler]

That's weird, I thought, only integers can be output.

It didn't return an integer because you never called the function. And it's not the WinGetMinMax that is expecting a string anyway. Like I said, you didn't show the full line that caused the error, because this alone doesn't cause an error, it just doesn't work right because you didn't pass the parameter to it:

Code: Select all

WinGetMinMax ("A")

This does cause the error, and it's because it's the MsgBox function that's expecting a string but got the name of a function (WinGetMinMax):

Code: Select all

MsgBox WinGetMinMax ("A")

[Seven0528]

　Comma

Comma is also used to delimit the parameters of a function call or control flow statement. To include a multi-statement expression in a parameter list, enclose it in an extra set of parentheses. For example, MyFn((x, y)) evaluates both x and y but passes y as the first and only parameter of MyFn.

Code: Select all

#Requires AutoHotkey v2.0
#SingleInstance Force
;  MsgBox [Text, Title, Options]
a:=1, b:=2

Msgbox(a,b) ;  This means a MsgBox with Text '1' and Title '2'.

Msgbox(b) ;  This means a MsgBox with Text '2' and an unset Title.
Msgbox (a,b)
Msgbox((a,b), unset)
Msgbox(format("{2}",a,b), unset)

Code: Select all

Msgbox "The current script has the following file extension:`t" (SplitPath(A_ScriptFullPath,,,&OutExtension), OutExtension) ;  The current script has the following file extension:	ahk
Msgbox "" (SplitPath(A_ScriptFullPath,,,&OutExtension), OutExtension) ;  ahk
Msgbox (SplitPath(A_ScriptFullPath,,,&OutExtension), OutExtension) ;  ahk

Code: Select all

GetFileExtension(Path:=A_ScriptFullPath)    {
    return (SplitPath(Path,,,&OutExtension), OutExtension) ;  ahk
}

[joefiesta]

I don't use V2, and one reason is this msgbox function.

why in the world would the V1 MSGBOX, options, title, text, timeout
syntax be rearranged to Msgbox(text,title,options) (that is, reordering the parameters)?

Is there a logical explanation for this?

[gregster]

Imo, it's a good change.
The most used syntax version of msgbox already in v1 is surely the simple MsgBox [, Text] variant, without options and title parameters.
msgbox is now a function in AHK v2. So there is only one syntax variant left.
So why not make the most important and most used parameter, text, the first one (like in most functions)? Instead of always having to add two commas in front of it for the often not used parameters... and many people would surely forget to add them, with unexpected results, because they rarely used the extended syntax option in v1.

The big version change which broke a lot of compatibility was surely the best opportunity to do away with the many syntax inconsistencies in v1.

[andymbody]

Imo, it's a good change.

Agreed

[RussF]

I suppose one could ask the question, "Why was the V1 syntax set up the way it was?". The argument order of the actual Windows API function MsgBox(), which AHK uses, is the same as that used in V2. Anyone using AHK that has called Windows API functions from another language will feel right at home - not confused as they were in V1.

Russ

[gregster]

I guess it was deemed more convenient for the user and easier to parse for the interpreter in command/legacy mode, since commas are also often part of the text parameter.

If you had something like this, with a single integer at the beginning between two commas: msgbox, 4, my title, some text, more text , it was assumed that 4 was meant as the Options parameter and not as literal text; and the next parameter, title, would probably contain commas more rarely than text: --> altogether less escaping of commas necessary in the actual text, since the following timeout parameter has to be a number again, if present.

If no options parameter is recognized, the simple msgbox syntax gets applied automatically:

Options
[...]
Any other non-blank value will not be recognized as this parameter, but instead as part of Text in the 1-parameter mode.

For a long time, expression syntax (and forcing expressions) was also more limited than today. After all, AHK v1 carries the baggage of 20 years

PS: It seems that this all was designed as "smart comma handling": compare, for example, https://www.autohotkey.com/docs/v1/AHKL_ChangeLog.htm#v1.1.06.00
Now, with functions - which always use expressions - this is obsolete.

[boiler]

I very much agree that the v2 MsgBox parameter order is better. And the two versions of the order in v1 just made things more difficult to remember. Since v2 is not backwards compatible, it thankfully did not have to carry forward the sins of v1.

[joefiesta]

thank you all who replied to my question:

• why in the world would the V1 MSGBOX, options, title, text, timeout
  syntax be rearranged to Msgbox(text,title,options) (that is, reordering the parameters)?

I think RussF hit it on the nail with:
[indent=]

I suppose one could ask the question, "Why was the V1 syntax set up the way it was?".

[/indent]

And, I certainly agree with ALL the replies. Excuse me, please, for being fussy. I grew up and worked with IBM mainframe systems and documentation for 30 years.
I was spoiled. But, let's face, they have WAY MORE $$$ and resources. AHK is still awesome, and very well documented. And if I didn't have 100,000 lines of AHK V1 code and weren't 72, I'd surely be converting to V2.

[Industry]

Thanks for the explanation ... At the end of the day, a stupid space caused this issue. How are users supposed to know that it makes a difference and to watch out for them? None of this is explained in the documentation. Especially coming from v1 where things like this were never an issue. The error message wasn't helping a novice user understand either.

The AHK language is supposed to be easy to pick up and easy to use. None of this was true here.

This is the whole line btw If (WinGetMinMax("A") = 1) ... not that complex. No reason to believe that it's a completely different interpretation than If (WinGetMinMax ("A") = 1)

[andymbody]

Especially coming from v1 where things like this were never an issue

I'm not sure I agree with this statement. v1 may have screamed less up front, but also led to unnecessary debugging when it remained silent. In v1 an error like this would have been indicated by the script just not working correctly, with no explanation why.

V2 will let you know up front that something is wrong with the code, and I think this will eventually be embraced as experience with it grows.

[boiler]

None of this is explained in the documentation.

It shows functions countless times with no space between the function name and the open parenthesis and not once with a space between them. Why should it have to specifically say not to put a space there? Where else should the documentation predict where you might insert extraneous characters and warn you not to do that?

Especially coming from v1 where things like this were never an issue.

Nope. Don’t know why you think that is true.

[Seven0528]

Thanks for the explanation ... At the end of the day, a stupid space caused this issue. How are users supposed to know that it makes a difference and to watch out for them? None of this is explained in the documentation. Especially coming from v1 where things like this were never an issue. The error message wasn't helping a novice user understand either.

The AHK language is supposed to be easy to pick up and easy to use. None of this was true here.

This is the whole line btw If (WinGetMinMax("A") = 1) ... not that complex. No reason to believe that it's a completely different interpretation than If (WinGetMinMax ("A") = 1)

　@Industry
Did you read the response I wrote?
Expressions using parentheses can be quite useful in certain situations.
Even if you don't feel the need for them personally, others may still find them necessary.

Code: Select all

;  1.
switch (userDefaultLocaleName:=A_.UserDefaultLocaleName)
{
    default:                strHello := "Hello"
    case "ja-JP":           strHello := "こんにちは"
    case "ko-KR":           strHello := "안녕하세요"
    case "zh-CN","zh-SG","zh-HK","zh-MO","zh-TW":
                            strHello := "你好"
}
Msgbox(strHello, userDefaultLocaleName)

Class A_ ;  v2.0
{
    static UserDefaultLocaleName    { ;  "en-US"
        get  { ;  https://learn.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getuserdefaultlocalename
            static LOCALE_NAME_MAX_LENGTH:=85
            lpLocaleName:=Buffer(bufferSize:=LOCALE_NAME_MAX_LENGTH*A_PtrSize, 0)
            length:=DllCall("Kernel32\GetUserDefaultLocaleName", "Ptr",lpLocaleName.Ptr, "Int",cchLocaleName:=LOCALE_NAME_MAX_LENGTH, "Int")
            return StrGet(lpLocaleName.Ptr, length, "UTF-16")
        }
    }
}

Code: Select all

;  2.
Msgbox (LOCALE_NAME_MAX_LENGTH:=85
        ,lpLocaleName:=Buffer(bufferSize:=LOCALE_NAME_MAX_LENGTH*A_PtrSize, 0)
        ,length:=DllCall("Kernel32\GetUserDefaultLocaleName", "Ptr",lpLocaleName.Ptr, "Int",cchLocaleName:=LOCALE_NAME_MAX_LENGTH, "Int")
        ,userDefaultLocaleName:=StrGet(lpLocaleName.Ptr, length, "UTF-16")
        ,userDefaultLocaleName=="ja-JP"?"こんにちは"
        :userDefaultLocaleName=="ko-KR"?"안녕하세요"
        :userDefaultLocaleName~="^zh"?"你好"
        :"Hello"), userDefaultLocaleName

Take a look at the following two pieces of code.
Personally, I prefer the first method, but there are other programmers who prefer the second approach,
and for the latter, the use of parentheses expression with space can be really helpful.

---

　And the fact that you couldn't find the relevant section in the official documentation doesn't mean it doesn't exist.
The relevant explanation is there, and the official documentation is extensive.
Keep in mind that there is no end to learning.

　#operators

There must be no space between the function name or expression and the open parenthesis which begins the parameter list. For details, see Function Calls.

　#comma

Comma is also used to delimit the parameters of a function call or control flow statement. To include a multi-statement expression in a parameter list, enclose it in an extra set of parentheses. For example, MyFn((x, y)) evaluates both x and y but passes y as the first and only parameter of MyFn.

　#legacy-syntax-removed

All control flow statements which take parameters (currently excluding the two-word Loop statements) support parentheses around their parameter list, without any space between the name and parenthesis. For example, return(var). However, these are not functions; for instance, x := return(y) is not valid. If and While already supported this.

　#expressions

Function calls now permit virtually any sub-expression for specifying which function to call, provided that there is no space or tab before the open-parenthesis of the parameter list.

---

　A programming language should be beginner-friendly, as we were all beginners at some point.
However, that doesn't mean that all documentation and warnings must be in a form that beginners can understand.
It is excessively inefficient and, in some cases, not even possible.
Above all, it is already happening differently than you think.
The official documentation is detailed on almost everything,
and discussions with questions and answers are taking place on the AHK forum, just as you are receiving responses to your questions now.

A programming language is 'a language', a convention for communication among multiple individuals.
While not perfect, there are sufficiently rational reasons for programming languages to adopt such syntax, unlike natural languages.
There will come a time when things you don't currently understand will become clear.
So, don't lose your perspective, but please be open to humbly accepting feedback from others.