In an application that I'm developing I have dim'd quite a few variables in
Declarations. I'll admit some of it is not wanting to take the time to put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique? All of
the application's code is in ONE module.

2) I got 'bitten' when testing a macro where a var called Draw was dim'd as
integer in Declarations, had a good value 0 in prior macros, but was 0 in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer in the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why did I
NOT get a duplicate Dim error?

Thanks.
--
Neal Z

By preference (and it's *mostly* preference), I try to declare only
procedure arguments and local (procedure-level) variables. This is
especially useful in large applications where one may not be sure that a
global/module-level variable isn't changed by an unrelated procedure.

You didn't get a duplicate Dim error because one variable was declared
at the module level, and one was declared within the sub. Local
variables always override global variables within their own procedure.
This is actually an advantage, as one can re-use variable names within
multiple procedures, but each procedure sees only its own, local
variable. For instance, note the reuse of "i" in:

Public Sub Sub1()
Dim i As Long
For i = 1 To 10
Sub2 "Iteration " & i & ": "
Next i
End Sub

Public Sub Sub2(ByVal sStr As String)
Dim i As Long
For i = 1 To 3
Debug.Print sStr & i
Next i
End Sub

If your code is fairly small, and will never be maintained by anyone
else, using module-level variables is probably fine, as long as you keep
track of which procedures are modifying them, and when.

If you're writing code that will be maintained by others, I'd strongly
recommend using local variables as much as possible.



In article ,
Neal Zimm wrote:

In an application that I'm developing I have dim'd quite a few variables in
Declarations. I'll admit some of it is not wanting to take the time to put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique? All of
the application's code is in ONE module.

2) I got 'bitten' when testing a macro where a var called Draw was dim'd as
integer in Declarations, had a good value 0 in prior macros, but was 0 in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer in the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why did I
NOT get a duplicate Dim error?

Ni Neal,

Neal Zimm wrote:
In an application that I'm developing I have dim'd quite a few
variables in Declarations. I'll admit some of it is not wanting to
take the time to put those vars that are used quite often in many
macros within the sub SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique?
All of the application's code is in ONE module.

I don't like to declare variables at module level or globally (Public
keyword in standard module) unless I have to. Some reasons are readability,
ease of maintenance, and knowing your variables won't be "trounced upon" by
various procedures. Module-level and global variables will also use more
resources.

The alternative is to pass variables via arguments to functions/subroutines.
It is undoubtedly more work upfront, but IMO it pays off to do it this way.

2) I got 'bitten' when testing a macro where a var called Draw was
dim'd as integer in Declarations, had a good value 0 in prior
macros, but was 0 in the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer
in the macro being tested. Hence the 0 value, I guess. The QUESTION
is, why did I NOT get a duplicate Dim error?

Well, since the variables had different scopes, it wasn't a duplicate
declaration. You had one module-level variable named Draw, and you had a
local variable named Draw with a completely different value.

--
Regards,

Jake Marx
MS MVP - Excel
www.longhead.com

[please keep replies in the newsgroup - email address unmonitored]

"Neal Zimm" wrote in message
...
In an application that I'm developing I have dim'd quite a few variables
in
Declarations. I'll admit some of it is not wanting to take the time to put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique? All
of
the application's code is in ONE module.

Personally, I try and keep this to a minimum, as it is always possible that
in a procedure the variable will have a residual value from a previous
procedure, preferring to use arguments. Yes, I know we should always
initialise, but it is too easy to be lazy and rely on the default initial
value.

The pros and the cons are the same things really, they keep the value across
procedures, they have (at least) module scope, and so on, it would depend
upon the application as to whether that is a pro or a con. What I am saying
I guess is that each variablke should be carefully considerred before either
placing in Declarations or a procedure.

2) I got 'bitten' when testing a macro where a var called Draw was dim'd
as
integer in Declarations, had a good value 0 in prior macros, but was 0
in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer in
the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why did
I
NOT get a duplicate Dim error?

Because it is not a duplicate. The first was a module scope variable, the
second was a procedure scope variable, it is quite legitimate to have both.
When you do, when in the procedure with the procedure scope variable will
be the one used, as you experienced.

Bob,

Back when I was starting with VBE (xl97) it seemed that double declarations
of a variable
such as Public x as Long (in the project) and Dim x as Long (in a module)
would sometimes cause Excel to crash.

Was I jumping to conclusions and it was really something else causing the
crash, or was that a problem with xl97?

--
steveB

Remove "AYN" from email to respond
"Bob Phillips" wrote in message
...
"Neal Zimm" wrote in message
...
In an application that I'm developing I have dim'd quite a few variables
in
Declarations. I'll admit some of it is not wanting to take the time to
put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique? All
of
the application's code is in ONE module.

Personally, I try and keep this to a minimum, as it is always possible
that
in a procedure the variable will have a residual value from a previous
procedure, preferring to use arguments. Yes, I know we should always
initialise, but it is too easy to be lazy and rely on the default initial
value.

The pros and the cons are the same things really, they keep the value
across
procedures, they have (at least) module scope, and so on, it would depend
upon the application as to whether that is a pro or a con. What I am
saying
I guess is that each variablke should be carefully considerred before
either
placing in Declarations or a procedure.

2) I got 'bitten' when testing a macro where a var called Draw was dim'd
as
integer in Declarations, had a good value 0 in prior macros, but was 0
in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer in
the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why
did
I
NOT get a duplicate Dim error?

Because it is not a duplicate. The first was a module scope variable, the
second was a procedure scope variable, it is quite legitimate to have
both.
When you do, when in the procedure with the procedure scope variable will
be the one used, as you experienced.

Good coding practice is to use global or module level variable declarations
as little as possible. The big reason is that it makes the code very
difficult to debug. At any given time it can be difficult to know the value
of a variable because all procedures can access it. One small change to one
procedure can have side effects on all of the procedures that access that
variable. The problem is that when you make the change it is not at all
obvious what all of the consequences are. If you are passing the variable
then it is reasonalby obvious. The only reasons that I ever use Globals a

1. I need a value determined at run time to persist. An example might be a
password to log into some subsystems. I get the user to enter it once and
that value is stored for as long as the program runs. Any time I need to log
into the subsystem I just call up the value. I don't have to worry about who
changed the value last becuase it is only set once at the beginning of
exectuion.

2. I have a function or sub procedure that is called repeatedly (great for
recursion). In order to speed up the exectution I will have it use global
variables so that the variables do not need to be created and destroyed each
time the procedure is called.
--
HTH...

Jim Thomlinson


"Neal Zimm" wrote:

In an application that I'm developing I have dim'd quite a few variables in
Declarations. I'll admit some of it is not wanting to take the time to put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique? All of
the application's code is in ONE module.

2) I got 'bitten' when testing a macro where a var called Draw was dim'd as
integer in Declarations, had a good value 0 in prior macros, but was 0 in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer in the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why did I
NOT get a duplicate Dim error?

Thanks.
--
Neal Z

Steve,

I can't say you were jumping to conclusions, but I must admit to never had
that experience myself. Excel has crashed on me a few times <g, but it was
usually attributable to me wrongly using APIs, or having a virus.

--

HTH

RP
(remove nothere from the email address if mailing direct)


"STEVE BELL" wrote in message
news:_%9Me.2938$Y55.855@trnddc06...
Bob,

Back when I was starting with VBE (xl97) it seemed that double
declarations
of a variable
such as Public x as Long (in the project) and Dim x as Long (in a module)
would sometimes cause Excel to crash.

Was I jumping to conclusions and it was really something else causing the
crash, or was that a problem with xl97?

--
steveB

Remove "AYN" from email to respond
"Bob Phillips" wrote in message
...
"Neal Zimm" wrote in message
...
In an application that I'm developing I have dim'd quite a few
variables
in
Declarations. I'll admit some of it is not wanting to take the time to
put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique?
All
of
the application's code is in ONE module.

Personally, I try and keep this to a minimum, as it is always possible
that
in a procedure the variable will have a residual value from a previous
procedure, preferring to use arguments. Yes, I know we should always
initialise, but it is too easy to be lazy and rely on the default
initial
value.

The pros and the cons are the same things really, they keep the value
across
procedures, they have (at least) module scope, and so on, it would
depend
upon the application as to whether that is a pro or a con. What I am
saying
I guess is that each variablke should be carefully considerred before
either
placing in Declarations or a procedure.

2) I got 'bitten' when testing a macro where a var called Draw was
dim'd
as
integer in Declarations, had a good value 0 in prior macros, but was
0
in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer in
the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why
did
I
NOT get a duplicate Dim error?

Because it is not a duplicate. The first was a module scope variable,
the
second was a procedure scope variable, it is quite legitimate to have
both.
When you do, when in the procedure with the procedure scope variable
will
be the one used, as you experienced.

How about if you're picking up tons of values from a worksheet(s) that are used
in lots of different subroutines.

I've used an initialization routine that returns all those values into global
variables.

Jim Thomlinson wrote:

Good coding practice is to use global or module level variable declarations
as little as possible. The big reason is that it makes the code very
difficult to debug. At any given time it can be difficult to know the value
of a variable because all procedures can access it. One small change to one
procedure can have side effects on all of the procedures that access that
variable. The problem is that when you make the change it is not at all
obvious what all of the consequences are. If you are passing the variable
then it is reasonalby obvious. The only reasons that I ever use Globals a

1. I need a value determined at run time to persist. An example might be a
password to log into some subsystems. I get the user to enter it once and
that value is stored for as long as the program runs. Any time I need to log
into the subsystem I just call up the value. I don't have to worry about who
changed the value last becuase it is only set once at the beginning of
exectuion.

2. I have a function or sub procedure that is called repeatedly (great for
recursion). In order to speed up the exectution I will have it use global
variables so that the variables do not need to be created and destroyed each
time the procedure is called.
--
HTH...

Jim Thomlinson

"Neal Zimm" wrote:

In an application that I'm developing I have dim'd quite a few variables in
Declarations. I'll admit some of it is not wanting to take the time to put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique? All of
the application's code is in ONE module.

2) I got 'bitten' when testing a macro where a var called Draw was dim'd as
integer in Declarations, had a good value 0 in prior macros, but was 0 in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer in the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why did I
NOT get a duplicate Dim error?

Thanks.
--
Neal Z

--

Dave Peterson

Use a class with properties, or maybe a collection class.

--

HTH

RP
(remove nothere from the email address if mailing direct)


"Dave Peterson" wrote in message
...
How about if you're picking up tons of values from a worksheet(s) that are
used
in lots of different subroutines.

I've used an initialization routine that returns all those values into
global
variables.

Jim Thomlinson wrote:

Good coding practice is to use global or module level variable
declarations
as little as possible. The big reason is that it makes the code very
difficult to debug. At any given time it can be difficult to know the
value
of a variable because all procedures can access it. One small change to
one
procedure can have side effects on all of the procedures that access
that
variable. The problem is that when you make the change it is not at all
obvious what all of the consequences are. If you are passing the
variable
then it is reasonalby obvious. The only reasons that I ever use Globals
a

1. I need a value determined at run time to persist. An example might be
a
password to log into some subsystems. I get the user to enter it once
and
that value is stored for as long as the program runs. Any time I need to
log
into the subsystem I just call up the value. I don't have to worry about
who
changed the value last becuase it is only set once at the beginning of
exectuion.

2. I have a function or sub procedure that is called repeatedly (great
for
recursion). In order to speed up the exectution I will have it use
global
variables so that the variables do not need to be created and destroyed
each
time the procedure is called.
--
HTH...

Jim Thomlinson

"Neal Zimm" wrote:

In an application that I'm developing I have dim'd quite a few
variables in
Declarations. I'll admit some of it is not wanting to take the time to
put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique?
All of
the application's code is in ONE module.

2) I got 'bitten' when testing a macro where a var called Draw was
dim'd as
integer in Declarations, had a good value 0 in prior macros, but was
0 in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer
in the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why
did I
NOT get a duplicate Dim error?

Thanks.
--
Neal Z

--

Dave Peterson

Bob,

The only thing else to add is that thanks to this group and some
experimenting with code - I did find many things in code that would crash
Excel. Since cleaning up "those" issues - I can't remember the last time my
code caused a crash.

I will continue to caution about declaring the same variable in and out of a
module.

Thanks for your input. And Dave's, and "Hi Every one else".

--
steveB

Remove "AYN" from email to respond
"Bob Phillips" wrote in message
...
Steve,

I can't say you were jumping to conclusions, but I must admit to never had
that experience myself. Excel has crashed on me a few times <g, but it
was
usually attributable to me wrongly using APIs, or having a virus.

--

HTH

RP
(remove nothere from the email address if mailing direct)


"STEVE BELL" wrote in message
news:_%9Me.2938$Y55.855@trnddc06...
Bob,

Back when I was starting with VBE (xl97) it seemed that double
declarations
of a variable
such as Public x as Long (in the project) and Dim x as Long (in a module)
would sometimes cause Excel to crash.

Was I jumping to conclusions and it was really something else causing the
crash, or was that a problem with xl97?

--
steveB

Remove "AYN" from email to respond
"Bob Phillips" wrote in message
...
"Neal Zimm" wrote in message
...
In an application that I'm developing I have dim'd quite a few
variables
in
Declarations. I'll admit some of it is not wanting to take the time to
put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique?
All
of
the application's code is in ONE module.

Personally, I try and keep this to a minimum, as it is always possible
that
in a procedure the variable will have a residual value from a previous
procedure, preferring to use arguments. Yes, I know we should always
initialise, but it is too easy to be lazy and rely on the default
initial
value.

The pros and the cons are the same things really, they keep the value
across
procedures, they have (at least) module scope, and so on, it would
depend
upon the application as to whether that is a pro or a con. What I am
saying
I guess is that each variablke should be carefully considerred before
either
placing in Declarations or a procedure.

2) I got 'bitten' when testing a macro where a var called Draw was
dim'd
as
integer in Declarations, had a good value 0 in prior macros, but was
0
in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer
in
the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why
did
I
NOT get a duplicate Dim error?

Because it is not a duplicate. The first was a module scope variable,
the
second was a procedure scope variable, it is quite legitimate to have
both.
When you do, when in the procedure with the procedure scope variable
will
be the one used, as you experienced.

Thanks to all for the sound advice, I hope y'all don't mind a common response.
I'm relatively new to the VB game, self taught (with help from this bulletin
board)
, and there's LOTS I don't know. (see later class variables.)

My uses of 'declared' vars in most cases, fall into all of the categories
mentioned.

1. vars where the values DON'T change, but are used by many subs. My
application is called "RM" and
I have a sub called zRM_Values which is called at the begining of larger
macros. (BTW, I have a bad
right pinky finger and typing quotes "" is a bother)

2 examples:

declared: dim Yes as string
in the zrm_values sub, Yes = "Y" , so in any other macro: if
other_var_name = yes then .....

declared: dim PressEnter as string
in zrm_values: PressEnter = "Press Enter or click OK after typing.." & vbcr
' used in inputbox dialogs


2. I have tried mightily to have the module declared vars fall into two
other categories:

a) they have the same meaning in any macro in the module so
if the value is changed, it's kinda a good thing for me that other macros
have access to the 'latest' value.

b) I don't care if the value changes.
example: dim x as integer

since I use option explicit, without dim'ing x in every procedure,
I can use: for x = 1 to whatever


3. I have not learned what a "class with properties" is yet, nor
what a collection class is. Is the Excel help adequate on this topic
or can you recommend other reading sources?

Again,
Thanks to all. Your help is very much appreciated.
Neal Z.
--
Neal Z


"Jim Thomlinson" wrote:

Good coding practice is to use global or module level variable declarations
as little as possible. The big reason is that it makes the code very
difficult to debug. At any given time it can be difficult to know the value
of a variable because all procedures can access it. One small change to one
procedure can have side effects on all of the procedures that access that
variable. The problem is that when you make the change it is not at all
obvious what all of the consequences are. If you are passing the variable
then it is reasonalby obvious. The only reasons that I ever use Globals a

1. I need a value determined at run time to persist. An example might be a
password to log into some subsystems. I get the user to enter it once and
that value is stored for as long as the program runs. Any time I need to log
into the subsystem I just call up the value. I don't have to worry about who
changed the value last becuase it is only set once at the beginning of
exectuion.

2. I have a function or sub procedure that is called repeatedly (great for
recursion). In order to speed up the exectution I will have it use global
variables so that the variables do not need to be created and destroyed each
time the procedure is called.
--
HTH...

Jim Thomlinson


"Neal Zimm" wrote:

In an application that I'm developing I have dim'd quite a few variables in
Declarations. I'll admit some of it is not wanting to take the time to put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique? All of
the application's code is in ONE module.

2) I got 'bitten' when testing a macro where a var called Draw was dim'd as
integer in Declarations, had a good value 0 in prior macros, but was 0 in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer in the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why did I
NOT get a duplicate Dim error?

Thanks.
--
Neal Z

Thanks to all for the sound advice, I hope y'all don't mind a common response.
I'm relatively new to the VB game, self taught (with help from this bulletin
board)
, and there's LOTS I don't know. (see later class variables.)

My uses of 'declared' vars in most cases, fall into all of the categories
mentioned.

1. vars where the values DON'T change, but are used by many subs. My
application is called "RM" and
I have a sub called zRM_Values which is called at the begining of larger
macros. (BTW, I have a bad
right pinky finger and typing quotes "" is a bother)

2 examples:

declared: dim Yes as string
in the zrm_values sub, Yes = "Y" , so in any other macro: if
other_var_name = yes then .....

declared: dim PressEnter as string
in zrm_values: PressEnter = "Press Enter or click OK after typing.." & vbcr
' used in inputbox dialogs


2. I have tried mightily to have the module declared vars fall into two
other categories:

a) they have the same meaning in any macro in the module so
if the value is changed, it's kinda a good thing for me that other macros
have access to the 'latest' value.

b) I don't care if the value changes.
example: dim x as integer

since I use option explicit, without dim'ing x in every procedure,
I can use: for x = 1 to whatever


3. I have not learned what a "class with properties" is yet, nor
what a collection class is. Is the Excel help adequate on this topic
or can you recommend other reading sources?

Again,
Thanks to all. Your help is very much appreciated.
Neal Z.
--
Neal Z


"JE McGimpsey" wrote:

By preference (and it's *mostly* preference), I try to declare only
procedure arguments and local (procedure-level) variables. This is
especially useful in large applications where one may not be sure that a
global/module-level variable isn't changed by an unrelated procedure.

You didn't get a duplicate Dim error because one variable was declared
at the module level, and one was declared within the sub. Local
variables always override global variables within their own procedure.
This is actually an advantage, as one can re-use variable names within
multiple procedures, but each procedure sees only its own, local
variable. For instance, note the reuse of "i" in:

Public Sub Sub1()
Dim i As Long
For i = 1 To 10
Sub2 "Iteration " & i & ": "
Next i
End Sub

Public Sub Sub2(ByVal sStr As String)
Dim i As Long
For i = 1 To 3
Debug.Print sStr & i
Next i
End Sub

If your code is fairly small, and will never be maintained by anyone
else, using module-level variables is probably fine, as long as you keep
track of which procedures are modifying them, and when.

If you're writing code that will be maintained by others, I'd strongly
recommend using local variables as much as possible.



In article ,
Neal Zimm wrote:

In an application that I'm developing I have dim'd quite a few variables in
Declarations. I'll admit some of it is not wanting to take the time to put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique? All of
the application's code is in ONE module.

2) I got 'bitten' when testing a macro where a var called Draw was dim'd as
integer in Declarations, had a good value 0 in prior macros, but was 0 in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer in the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why did I
NOT get a duplicate Dim error?

Thanks to all for the sound advice, I hope y'all don't mind a common response.
I'm relatively new to the VB game, self taught (with help from this bulletin
board)
, and there's LOTS I don't know. (see later class variables.)

My uses of 'declared' vars in most cases, fall into all of the categories
mentioned.

1. vars where the values DON'T change, but are used by many subs. My
application is called "RM" and
I have a sub called zRM_Values which is called at the begining of larger
macros. (BTW, I have a bad
right pinky finger and typing quotes "" is a bother)

2 examples:

declared: dim Yes as string
in the zrm_values sub, Yes = "Y" , so in any other macro: if
other_var_name = yes then .....

declared: dim PressEnter as string
in zrm_values: PressEnter = "Press Enter or click OK after typing.." & vbcr
' used in inputbox dialogs


2. I have tried mightily to have the module declared vars fall into two
other categories:

a) they have the same meaning in any macro in the module so
if the value is changed, it's kinda a good thing for me that other macros
have access to the 'latest' value.

b) I don't care if the value changes.
example: dim x as integer

since I use option explicit, without dim'ing x in every procedure,
I can use: for x = 1 to whatever


3. I have not learned what a "class with properties" is yet, nor
what a collection class is. Is the Excel help adequate on this topic
or can you recommend other reading sources?

Again,
Thanks to all. Your help is very much appreciated.
Neal Z.
--
Neal Z


"Jake Marx" wrote:

Ni Neal,

Neal Zimm wrote:
In an application that I'm developing I have dim'd quite a few
variables in Declarations. I'll admit some of it is not wanting to
take the time to put those vars that are used quite often in many
macros within the sub SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique?
All of the application's code is in ONE module.

I don't like to declare variables at module level or globally (Public
keyword in standard module) unless I have to. Some reasons are readability,
ease of maintenance, and knowing your variables won't be "trounced upon" by
various procedures. Module-level and global variables will also use more
resources.

The alternative is to pass variables via arguments to functions/subroutines.
It is undoubtedly more work upfront, but IMO it pays off to do it this way.

2) I got 'bitten' when testing a macro where a var called Draw was
dim'd as integer in Declarations, had a good value 0 in prior
macros, but was 0 in the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer
in the macro being tested. Hence the 0 value, I guess. The QUESTION
is, why did I NOT get a duplicate Dim error?

Well, since the variables had different scopes, it wasn't a duplicate
declaration. You had one module-level variable named Draw, and you had a
local variable named Draw with a completely different value.

--
Regards,

Jake Marx
MS MVP - Excel
www.longhead.com

[please keep replies in the newsgroup - email address unmonitored]

Thanks to all for the sound advice, I hope y'all don't mind a common response.
I'm relatively new to the VB game, self taught (with help from this bulletin
board)
, and there's LOTS I don't know. (see later class variables.)

My uses of 'declared' vars in most cases, fall into all of the categories
mentioned.

1. vars where the values DON'T change, but are used by many subs. My
application is called "RM" and
I have a sub called zRM_Values which is called at the begining of larger
macros. (BTW, I have a bad
right pinky finger and typing quotes "" is a bother)

2 examples:

declared: dim Yes as string
in the zrm_values sub, Yes = "Y" , so in any other macro: if
other_var_name = yes then .....

declared: dim PressEnter as string
in zrm_values: PressEnter = "Press Enter or click OK after typing.." & vbcr
' used in inputbox dialogs


2. I have tried mightily to have the module declared vars fall into two
other categories:

a) they have the same meaning in any macro in the module so
if the value is changed, it's kinda a good thing for me that other macros
have access to the 'latest' value.

b) I don't care if the value changes.
example: dim x as integer

since I use option explicit, without dim'ing x in every procedure,
I can use: for x = 1 to whatever


3. I have not learned what a "class with properties" is yet, nor
what a collection class is. Is the Excel help adequate on this topic
or can you recommend other reading sources?

Again,
Thanks to all. Your help is very much appreciated.
Neal Z.
--
Neal Z


"Bob Phillips" wrote:

Use a class with properties, or maybe a collection class.

--

HTH

RP
(remove nothere from the email address if mailing direct)


"Dave Peterson" wrote in message
...
How about if you're picking up tons of values from a worksheet(s) that are
used
in lots of different subroutines.

I've used an initialization routine that returns all those values into
global
variables.

Jim Thomlinson wrote:

Good coding practice is to use global or module level variable
declarations
as little as possible. The big reason is that it makes the code very
difficult to debug. At any given time it can be difficult to know the
value
of a variable because all procedures can access it. One small change to
one
procedure can have side effects on all of the procedures that access
that
variable. The problem is that when you make the change it is not at all
obvious what all of the consequences are. If you are passing the
variable
then it is reasonalby obvious. The only reasons that I ever use Globals
a

1. I need a value determined at run time to persist. An example might be
a
password to log into some subsystems. I get the user to enter it once
and
that value is stored for as long as the program runs. Any time I need to
log
into the subsystem I just call up the value. I don't have to worry about
who
changed the value last becuase it is only set once at the beginning of
exectuion.

2. I have a function or sub procedure that is called repeatedly (great
for
recursion). In order to speed up the exectution I will have it use
global
variables so that the variables do not need to be created and destroyed
each
time the procedure is called.
--
HTH...

Jim Thomlinson

"Neal Zimm" wrote:

In an application that I'm developing I have dim'd quite a few
variables in
Declarations. I'll admit some of it is not wanting to take the time to
put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique?
All of
the application's code is in ONE module.

2) I got 'bitten' when testing a macro where a var called Draw was
dim'd as
integer in Declarations, had a good value 0 in prior macros, but was
0 in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer
in the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why
did I
NOT get a duplicate Dim error?

Thanks.
--
Neal Z

--

Dave Peterson

Thanks to all for the sound advice, I hope y'all don't mind a common response.
I'm relatively new to the VB game, self taught (with help from this bulletin
board)
, and there's LOTS I don't know. (see later class variables.)

My uses of 'declared' vars in most cases, fall into all of the categories
mentioned.

1. vars where the values DON'T change, but are used by many subs. My
application is called "RM" and
I have a sub called zRM_Values which is called at the begining of larger
macros. (BTW, I have a bad
right pinky finger and typing quotes "" is a bother)

2 examples:

declared: dim Yes as string
in the zrm_values sub, Yes = "Y" , so in any other macro: if
other_var_name = yes then .....

declared: dim PressEnter as string
in zrm_values: PressEnter = "Press Enter or click OK after typing.." & vbcr
' used in inputbox dialogs


2. I have tried mightily to have the module declared vars fall into two
other categories:

a) they have the same meaning in any macro in the module so
if the value is changed, it's kinda a good thing for me that other macros
have access to the 'latest' value.

b) I don't care if the value changes.
example: dim x as integer

since I use option explicit, without dim'ing x in every procedure,
I can use: for x = 1 to whatever


3. I have not learned what a "class with properties" is yet, nor
what a collection class is. Is the Excel help adequate on this topic
or can you recommend other reading sources?

Again,
Thanks to all. Your help is very much appreciated.
Neal Z.
--
Neal Z


"Bob Phillips" wrote:

"Neal Zimm" wrote in message
...
In an application that I'm developing I have dim'd quite a few variables
in
Declarations. I'll admit some of it is not wanting to take the time to put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique? All
of
the application's code is in ONE module.

Personally, I try and keep this to a minimum, as it is always possible that
in a procedure the variable will have a residual value from a previous
procedure, preferring to use arguments. Yes, I know we should always
initialise, but it is too easy to be lazy and rely on the default initial
value.

The pros and the cons are the same things really, they keep the value across
procedures, they have (at least) module scope, and so on, it would depend
upon the application as to whether that is a pro or a con. What I am saying
I guess is that each variablke should be carefully considerred before either
placing in Declarations or a procedure.

2) I got 'bitten' when testing a macro where a var called Draw was dim'd
as
integer in Declarations, had a good value 0 in prior macros, but was 0
in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer in
the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why did
I
NOT get a duplicate Dim error?

Because it is not a duplicate. The first was a module scope variable, the
second was a procedure scope variable, it is quite legitimate to have both.
When you do, when in the procedure with the procedure scope variable will
be the one used, as you experienced.

Neal,

"Neal Zimm" wrote in message
...
Thanks to all for the sound advice, I hope y'all don't mind a common
response.
I'm relatively new to the VB game, self taught (with help from this
bulletin
board)
, and there's LOTS I don't know. (see later class variables.)

My uses of 'declared' vars in most cases, fall into all of the categories
mentioned.

1. vars where the values DON'T change, but are used by many subs. My
application is called "RM" and
I have a sub called zRM_Values which is called at the begining of larger
macros. (BTW, I have a bad
right pinky finger and typing quotes "" is a bother)

2 examples:

declared: dim Yes as string
in the zrm_values sub, Yes = "Y" , so in any other macro: if
other_var_name = yes then .....

declared: dim PressEnter as string
in zrm_values: PressEnter = "Press Enter or click OK after typing.." &
vbcr
' used in inputbox dialogs

This sound more like a constant than a variable

Const Yes As String = "Y"

declared and initialised in one statemenmt

2. I have tried mightily to have the module declared vars fall into two
other categories:

a) they have the same meaning in any macro in the module so
if the value is changed, it's kinda a good thing for me that other macros
have access to the 'latest' value.

b) I don't care if the value changes.
example: dim x as integer

since I use option explicit, without dim'ing x in every procedure,
I can use: for x = 1 to whatever


3. I have not learned what a "class with properties" is yet, nor
what a collection class is. Is the Excel help adequate on this topic
or can you recommend other reading sources?

I would suggest at this stage you don't bother with classes. Whilst they are
useful, they are rarely an absolute necessity. My point was really at Dave's
statement.

Absolutely the same as a constant. Many thanks. I'm changing the code now.
you have helped me knock out about 40% of the declared vars.
--
Neal Z


"Bob Phillips" wrote:

Neal,

"Neal Zimm" wrote in message
...
Thanks to all for the sound advice, I hope y'all don't mind a common
response.
I'm relatively new to the VB game, self taught (with help from this
bulletin
board)
, and there's LOTS I don't know. (see later class variables.)

My uses of 'declared' vars in most cases, fall into all of the categories
mentioned.

1. vars where the values DON'T change, but are used by many subs. My
application is called "RM" and
I have a sub called zRM_Values which is called at the begining of larger
macros. (BTW, I have a bad
right pinky finger and typing quotes "" is a bother)

2 examples:

declared: dim Yes as string
in the zrm_values sub, Yes = "Y" , so in any other macro: if
other_var_name = yes then .....

declared: dim PressEnter as string
in zrm_values: PressEnter = "Press Enter or click OK after typing.." &
vbcr
' used in inputbox dialogs

This sound more like a constant than a variable

Const Yes As String = "Y"

declared and initialised in one statemenmt

2. I have tried mightily to have the module declared vars fall into two
other categories:

a) they have the same meaning in any macro in the module so
if the value is changed, it's kinda a good thing for me that other macros
have access to the 'latest' value.

b) I don't care if the value changes.
example: dim x as integer

since I use option explicit, without dim'ing x in every procedure,
I can use: for x = 1 to whatever


3. I have not learned what a "class with properties" is yet, nor
what a collection class is. Is the Excel help adequate on this topic
or can you recommend other reading sources?

I would suggest at this stage you don't bother with classes. Whilst they are
useful, they are rarely an absolute necessity. My point was really at Dave's
statement.