If that code all came directly from your book... then, personally, I would
throw the book away and buy a different one. Okay, maybe that was too
drastic a statement<g>, but there are two things in those three code lines
that I do not like.
The first is the use of the postfix symbol (the % sign) in place of a
spelled out type declaration. The % sign, when attached to a variable or
number, is a shortcut method of declaring an Integer. I've been programming
in one form of BASIC/Visual Basic for some 27 years now... I cut my teeth on
the language using postfix declarations... and to this day, I still can't
look at one of those declarations and tell you which one is which (with the
exception of $ for Strings). I would have declared the NewVar variable like
this...
Dim NewVar As Integer
That is much easier to read, don't you think?
The second thing I don't like is in the last line... unless parentheses are
required by syntax (or used to clarify the order of expression evaluation),
you should not use them. In this particular case, the parentheses won't hurt
(I'll explain why in a moment), but if you decided to specify one of the
optional argument (like forcing a question mark symbol by adding vbQuestion
as a second argument), then you would get an error message. For example,
this works fine...
MsgBox (NewVar)
but this one won't...
MsgBox (NewVar, vbQuestion)
On the other hand, this works as expected...
MsgBox "Hello", vbQuestion
Because the MsgBox "function" is being called like a subroutine, the
parentheses are not required by syntax, so they should be left off. There
are two ways to call a subroutine...
YourSubroutine Argument1, Argument2
or
Call YourSubroutine(Argument1, Argument2)
When you use the Call keyword, the parentheses are required; if you don't
use the Call keyword, the are not required. By the way, if you used the
MsgBox "function" as a function (that is, using the value returned from it),
then the parentheses are required. For example,
ReturnValue = MsgBox(NewVar, vbQuestion)
Okay, now here is something I have posted over in the compiled VB newsgroups
in the past that explains why the single argument version of the MsgBox
statement worked with the parentheses and the double argument version did
not....
VB treats things in parentheses as expressions to be evaluated (even if that
thing is not really considered an expression, such as a variable name). If
your method or subroutine call requires two arguments (or more), encasing
them in one set of parentheses will force an error to be generated as a
comma separated list is not a proper expression that VB can evaluate. The
real problem comes with arguments that are supposed to be passed ByRef (by
reference)... a parentheses-encased argument will force VB to pass the
memory address of the temporary memory location used to evaluate the
expression and that is what the subroutine will use to write back its ByRef
argument to... which means the original variable which was supposed to be
updated by the subroutine will not be (no error will be generated, but your
results will be incorrect). Here is a short example to show you what I mean.
Copy/Paste the following two subroutines into a code window and run the
TestMe subroutine (read the comments to see what is being demonstrated)...
Sub TestMe()
Dim MyNumber As Double
' Set the value of MyNumber to a value, say 4
MyNumber = 4
' This next statement will generate the correct value
' of 16 (note that no parentheses are used).
SquareMe MyNumber
MsgBox MyNumber
' Reset the value of variable back to its original value
MyNumber = 4
' This next statement will generate the wrong value
' because it is surrounded in parentheses.
SquareMe (MyNumber)
MsgBox MyNumber
End Sub
Sub SquareMe(ByRef X As Double)
X = X * X
End Sub
The SquareMe subroutine takes its passed value, multiplies it by itself and
then uses the fact that it was passed ByRef to send the updated value back
to the calling code by assigning the new value directly to the passed
argument. When no parentheses surround the argument, the variable is updated
correctly; but when the argument is surrounded by parentheses, the variable
does not get updated (the calculated variable was returned to the temporary
memory location where the "expression" was evaluated at before being passed
to the subroutine instead of the actual memory address of the variable
itself.
Rick
