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.