Messagebox not compiling when within parentheses

HCL Domino Domino Forum
1

I am seeing some very unusual behavior when writing a messagebox command. I always enclose my messagebox code within parentheses as a matter of personal style, but when I attempted to do so on a particular line of code within a subroutine, the script will not compile. When I remove the “offending” parentheses, the script compiles just fine. Here’s the code:

returnStringMessage = "Entries for the following per diem entries could not be completely processed due to date errors." +Chr(10)+"Please adjust them individually."+Chr(13)+Chr(13)

returnStringMessage=returnStringMessage+returnString	

Messagebox (returnStringMessage,64,"Entry Errors")

And here’s the odd error message that shows up in the error line:

[subname]: 52: Unexpected: ,;Expected: Operator;)

Has anyone else seen anything like this? I use messageboxes throughout this application as well as other applications, and this is the first time I’ve observed this behavior in Designer.

2

Subject: RE: Messagebox not compiling when within parentheses

Anytime you use a function or subroutine, including a system function, you have two choices (for a subroutine) or three (for a function).*

For a function, you can use the function call syntax FuncName(arg1, arg2). But to use the function call syntax, you must do something with the return value. E.g: result = FuncName(arg1, arg2) or Print FuncName(arg1, arg2).

For a subroutine or a function, you can use the statement syntax (discarding the return value, if it’s a function). E.g.:

SubOrFuncName arg1, arg2

For a subroutine or function, you can use the Call syntax, e.g.:

Call SubOrFuncName(arg1, arg2)

You can legally use Call and include parens, or leave off Call and also leave off the parens. You can’t leave off Call and still use parens, as you were trying to do.

Some people get confused about this because if a subroutine or function has one argument, in many cases you can use the statement syntax and include parens, e.g.:

SubOrFuncName(x)

In this case, strange as it may seem, the parenthesis are considered not to enclose the list of arguments, but only the first argument – there just happens to be only one. These parens actually have a functional meaning – they force the argument to be passed by value – the subroutine is given a copy, so that it can’t alter the original value.† The equivalent Call syntax would be:

Call SubOrFuncName((x))

Or if there are multiple arguments, you might write something like this:

SubOrFuncName x, (y), z

You can enclose a single argument in parenthesis, and the previous example was the degenerate case where there was only one argument, that that argument is in parens.

But you can’t write:

SubOrFuncName(x, y) ’ wrong!

for the same reason you can’t do the following assignment:

a = (x, y)

In the statement syntax, parens are expected to enclose an expression, not a list of parameters. So when the parser sees a comma after x, it gets confused. In an expression, you can’t use a comma right after a variable name or constant – the parser was expecting to see either an operator (e.g. “+”) or the close paren. Does that make the error message clearer?

  • If I don’t mention it, some picky person will probably point out that for many system functions you can only use the function syntax. Messagebox is not one of these.

† Not all types of variables can be treated in this way, so depending on how x is declared, in some cases this syntax may still be illegal.

3

Subject: maybe your msg is too long?

from Designer Help:

Note The length of message is dependent on the operating system. If you are launching applications in a mixed environment (for example, PC and Mac), keep your message length equal to or shorter than the smallest limit of the operating systems to be used.

Use the newline character to force line breaks in the message element. Or use vertical bars or braces to specify a multiline string. If you don’t force line breaks, the text wraps automatically in the message box.

Note Newline does not mean either chr(10) or chr(13) on all platforms. Newline is the character or sequence of characters that is used to mark the end of a line. This may be chr(10), or chr(13), but it may also be something else, because the actual value of newline depends on the platform. If newlines are desired in the output, it is the programmer’s responsibility to ensure that the string contains the correct newline for the platform.