>
It seems to work the way I expect. It also retained its value after I
forced an unhandled error. I also tried:
No, it will not retain the value.
So, all that trouble to define a function (that is ALSO GLOBAL) does not
gain you anything at all.
>
Some of the ideas from the thread were an interface, a class module and
a custom collection. In Access, is there any potential benefit in
using static variables to hold global values?
No, there is no benefit. If you need some global variables, then define some
global variables. End of story. However, you BETTER not be define some
variables global that DO NOT NEED TO BE GLOBAL.
So, we taking about a apples and oranges types problems. Further, your
static examples force you to define a function, and additional code (and,
worse, those functions + additional code is ALSO GLOBAL!!! - how then can
this code be merged *safely* into other exiting projects? Global functions
are just as bad as global vars.
Also, as mentioned, an un-handled error will re-set those values anyway (I
don't know how you tested this..but, they do re-set).
Anyway, the re-setting of variables is a MOOT point, and is another
different
fruit again. (since I *always* distribute a mde to my users, and un-handled
errors in a mde DO NOT re-set the variables - so, that never a problem we
need to solve is it? ).
However, the problem discussed, and the solution suggested (by that c++
developer) is not a way to use global vars, but A WAY TO AVOID using them.
We all know the evils of global vars, and the cost/difficulty in
maintaining code as such.
The problem raised here is that when you have a subroutine/function and
EXIT, then all of the values go out of scope. So, a often used (and poor)
workaround is to start declaring global variables to hold and maintain those
values. It is VERY VERY VERY important to note that in this example we are
using global vars to keep a set of variables for a PARTICULAR PIECE OF CODE.
When we say particular, we simply are NOT talking about a variable that
SHOULD BE global (but, only being done because that is what the langue
offers, or the developer is lazy). So, the rule still remains that you ONLY
should use global vars when you need them to be global.
However, the problem is that often the ONLY mechanism a developer has to
keep variables alive is global vars. So, we NEVER want to use global vars to
simply pass values to another subroutine (assuming we have other reasonable
choices). However, if scope comes into play, then a fall back is to use
global. Of course, as programming languages got better, then we received
features like "static". Static means that we can *keep* values in a routine,
and NOT have to declare global vars due to scope issues. So, the suggestion
being made is that if you don't actually need global, then don't use them.
And, often, that fallback position to use global can be eliminated by using
static variables. If that value is ONLY needed for that particular routine,
then we have NO business declaring that variables as a global..
By the way, for the sake of this discussions, global vars, global functions,
global subs, global class objects, or whatever ARE ALL THE SAME CONCEPT.
They
ALL SUFFER FROM the same problems. There is little, if ANY value in removing
a global variable, but then turning around and crating a global function to
accomplish the same thing (in fact, it means you accomplish nothing).
So,
* the issue of un-handled errors, and variables re-setting is a
separate issue from the variable "scope"
* global variables, or global functions are still evil, and
should be avoided
* The suggested idea to use static declaring for variables makes
a lot of sense
* only things that are global to the application need be
declared global
* really, no difference between global variables, and
global functions - they suffer the same ills.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com 
