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