Declarations variables, Dim, some guidance please
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.
|