Changing the name of a message box

  • Thread starter Thread starter Bishop
  • Start date Start date
This is where referring to the Help files helps (put cursor in or next to
the MsgBox keyword and press F1)... it explains what the optional arguments
mean. You want to assign something to the Title argument...

MsgBox "HI", Title:="This is my title"
 
Remove the parentheses... while they will work if the MsgBox command is
called as a subroutine (rather than if it is called as a function) if only
one argument is specified, using the parentheses with more than one argument
(again, when called as a subroutine) will always generate an error. For
subroutine calls, there are only two reliable methods, either this way...

Command Arg1, Arg2, etc

or this way...

Call Command(Arg1, Arg2, etc)

You can use the parentheses only with the second calling method. So, you
need to do your call either this way....

MsgBox "Fill in this information before continuing.", , "WARNING!"

or this way...

Call MsgBox("Fill in this information before continuing.", , "WARNING!")

Note - You do not need to specify trailing commas if there no additional
optional arguments following them.

--
Rick (MVP - Excel)


Bishop said:
Apparently I'm not understanding the syntax involved. I totally see what
you're talking about but the help file example isn't very helpful. This
is
what I've tried:
MsgBox ("You have to fill in this information before you can
continue.",,"WARNING!",,)
I've tried every combination with and without , placeholders. I've tried
using no quotes. And I either get a "= expected" error or an "expression"
error.

The syntax required in the helpfile is: MsgBox(prompt[, buttons] [, title]
[, helpfile, context])

So why doesn't this work?


Patrick Molloy said:
yes

the syntax is

msgbox prompt, buttons, title

VBA intellisence gives you the full list, but basically, whatever you use
as
"title" will appear as the heading
Click to expand...
Click to expand...
 
Just to be clear, you are using MsgBox as a subroutine in Method 1 and as a
function in Method 2 (you are testing a value that is returned from the
MsgBox call)... when used as a function, parentheses are required, when used
as a subroutine, they are only mandatory when the Call keyword is used and a
mistake to use otherwise. Here is the reason why as I explained it in an old
posting of mine...

As others have shown without specifically pointing to the reason, your
problem stems from the parentheses. MsgBox is a function and when used to
return a value, such as like this...

Answer = MsgBox("Here is a question", vbYesNo Or vbQuestion)

the parentheses are required. When no value is returned, the function
effectively becomes a subroutine. There are two proper ways to call a
subroutine...

Call MsgBox("Here is a question", vbYesNo Or vbQuestion)

and

MsgBox "Here is a question", vbYesNo Or vbQuestion

Note that when Call is used, the parentheses are required; however, when the
Call keyword is omitted, the parentheses are syntactically incorrect. So you
are probably asking, "Why did it work when I didn't add the 2nd argument?"
Good question. It seems that when parentheses are used in a statement that
are not required by syntax, VB assumes it has an expression to evaluate and,
well, it attempts to evaluate the contents of the parentheses. When you
specified only a single text argument, VB could evaluate it... it simply
evaluates as itself. But, when you added the 2nd argument, VB has no
mechanism to evaluate two expressions without an operator of some kind
between them (the comma is not an expression operator), so it generated an
error. The bottom line is to use parentheses in a subroutine statement
**only** when they are required by syntax (do not use them to "pretty"
things up as doing that will create problems in more situations than the one
I just outlined).
 
I'm trying to think of when I would want a Yes and No button on an
informational message box. Kind of like those things on a boar hog. <g>
 
Dim Resp as long
resp = msgbox(Prompt:="are you sure you'd never want yes/no?", buttons:=vbYesNo)

if resp = xlyes then
msgbox "Really?"
else
msgbox "I thought there'd be an instance"
end if
 
But when you assign the result to a variable, it is no longer just
informational. It then becomes functional. Dave's response changed the
character of the statement.

Rick Rothstein said:
LOL... I just loved your response, it was perfect!
Click to expand...
 
Oh, I see what you mean... I used vbYesNo as part of the MsgBox example in
my caution. When you said "informational", you meant when called as a
subroutine... for that usage, you are right, there would be no need for
anything but the default OK button because there will be no code examining
the response. My caution about the parentheses still applies though (you
just wouldn't be modifying the number of buttons when specifying multiple
arguments). My example should have been something like this instead...

MsgBox "Doing that may cause a problem!", vbExclamation"

--
Rick (MVP - Excel)


JLGWhiz said:
But when you assign the result to a variable, it is no longer just
informational. It then becomes functional. Dave's response changed the
character of the statement.
Click to expand...
 
Every once in awhile, I'll see someone use Call with functions built into
excel's VBA. I find it confusing and distracting (but I'm easily confused and
distracted).

The same goes for seeing code like:
mystr = VBA.Trim(mystr)

If they use it for trim, then they should use it for all.


But when you assign the result to a variable, it is no longer just
informational. It then becomes functional. Dave's response changed the
character of the statement.
Click to expand...
 
Right, when it does nothing but deliver a message, it is informational.
When it returns a value to a variable it is functional. So, if you do not
expect a response from the user, the there is no need for a Yes, No or
Cancel, or Question option. The Information, Exclamation and Critical could
still be cogent options. The OK button will show up if no other button is
specified.
 
For those reading this thread, I just want to make it clear that, while
directed toward the MsgBox, my comments about the use of parentheses with
subroutines are fully applicable to subroutines in general, not just when
the MsgBox is used as a subroutine.
 
The Information, Exclamation and Critical could still be cogent options.

Including the Title is another way to have two (or more) arguments in a
MsgBox, so the proper use of parentheses should still be observed.
 
Back
Top