Variable Declaration

  • Thread starter Thread starter R Tanner
  • Start date Start date
R

R Tanner

Hi,

I'm reading a book learning how to program and I'm walking through an
example talking about variable declaration. I understand what the
following procedure is doing, but I don't understand what the purpose
of it is. Can anyone help me to understand why I would do this?

Sub Create_Var()

Dim NewVar%
NewVar = "45"
MsgBox (NewVar)

End Sub

Thanks,
 
it is displaying or demonstrating,
how to create a variable. in this case a variant.
put a value to it.
and display it in a message box
 
why doesn't it say

Dim NewVar as Variant

& what's the percentage sign for?

:)
not-a-newbie-but-never-seen-this!
susan
 
i believe it means to declare it as an integer.

--


Gary


why doesn't it say

Dim NewVar as Variant

& what's the percentage sign for?

:)
not-a-newbie-but-never-seen-this!
susan
 
Why would it, should it, say As Varaint, that is sloppy programming.

The % is short notation for As Integer, but it is a bit old hat, and not
really a good practice.

--
__________________________________
HTH

Bob

why doesn't it say

Dim NewVar as Variant

& what's the percentage sign for?

:)
not-a-newbie-but-never-seen-this!
susan
 
They are showing you a few things. One is how to declare a variable using a
dim statement. Secondly they are showing you a non-standard way of defining
the type of variable it is. By adding the % sign at the end they are
declaring the varaible of type integer. Thirdly they are showing you implicit
type conversion. Note that they are passing a string "45" into an integer.
When the variable receives the string it converts it to the number 45. If it
was me I would have written the code like this...

sub MySub()
dim lngMyNumber as long

lngMyNumber = 45
msgbox lngMyNumber
end sub

Note that I used a long instead of an integer. On a 32 bit machine there is
no benfit to using an integer and actually a few drawbacks.
 
Personally, I would throw that book starigt in the bin if I were you.


Dim NewVar%

Nothing specifically wrong with this, but type declaration characters are a
bit old-hat, and it is far better to be specific as with As Long

NewVar = "45"

It is an integer variable so he puts the value in quotes - what a load of
.....

MsgBox (NewVar)

By enclosing the variable in parentheses it gets evaluated before being
passed to MsgBox. As it is a simple variable it is unnecessary, and this
sort of notation is not needed and should not be used until if and when that
particular syntax is explained.
 
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
 
Now that is funny! You had **exactly** the same reaction to the OP's post
that I did... **exactly**.

Rick
 
Any time I declare a variant I always specify it as being variant. It just
tells the user that I actually thought about it and have made the conscious
decision to have a variant.

All too often I see something like
Dim x
where the coder just didn't take the time to specify the type even though as
you read through the code it becomes obvious what the type should have been.

Sometimes I even spell Variant correctly but it you never bother to declare
your variable as being of type variant I guess it doesn't matter... ;-) And I
am the last person who should be complaingin about typo's in thos forum...
 
Bob said:
Why would it, should it, say As Varaint, that is sloppy >programming.
Click to expand...

i said variant because that's what greg said - i wasn't really
focusing on what type of data it was, i was more interested in the
shorthand, which i definitely do not like!
thanks everybody for all the answers
susan
 
Jim Thomlinson said:
Any time I declare a variant I always specify it as being variant. It just
tells the user that I actually thought about it and have made the
conscious
decision to have a variant.

All too often I see something like
Dim x
where the coder just didn't take the time to specify the type even though
as
you read through the code it becomes obvious what the type should have
been.
Click to expand...

I think you are referring to something slightly different Jim. I think you
are saying that if you have a variable that might take different data types,
you explicitly declare it as Variant rather than leave it as an implicit
declaration. Here the data is numeric, so should NOT be left as an implicit
or declared as an explicit variant type, IMO.
 
I like to think of it as "I gave a detailed explanation behind the problems"
that were being pointed out... well, at least for the extraneous parentheses
problem that is.<g>

Rick
 
i said variant because that's what greg said - i wasn't really
focusing on what type of data it was, i was more interested in the
shorthand, which i definitely do not like!
thanks everybody for all the answers
susan
Click to expand...

Okay if I should scrap it are there any recommendations on good books
to read?
 
John Walkenbach's books are good! i have "Excel 2000 Power
Programming with VBA".
susan
Click to expand...

Yeah I have read through the first 200 pages or so at Barnes and
Noble, but never actually bought it. I didn't really start to learn
anything until I got to about 180 or so, but it definitely looks like
a good book. Thanks for the recommend.
 
Back
Top