Difference between a global and public variable

[laavista]

What is the difference between a global and public variable?

Thanks, in advance, for your help.

 

[Tom van Stiphout]

On Thu, 16 Apr 2009 21:14:01 -0700, laavista

If they are declared in a standard module, there is no difference.

Global is not allowed in form or report modules. In those modules,
Public has module-scope.

-Tom.
Microsoft Access MVP

 

[Allen Browne]

What is the difference between a global and public variable?

By a 'global' variable, we usually mean a public variable of unlimited scope
and lifetime. Typically it is declared in the General Declarations section
(top) of a standard module (not a class module), so that it is always
available anywhere.

 

[Armen Stein]

By a 'global' variable, we usually mean a public variable of unlimited scope
and lifetime.

Yes, unlimited lifetime under normal circumstances. However, be aware
that your Global values will be cleared when:

- stopping your code while debugging (won't happen in normal usage)

- trapping for the 'X' button closure of the database by canceling the
Unload event of a form. Unfortunately Access clears all the Globals
before it realizes that you are going to keep the app open.

Some developers avoid Globals by placing controls on a hidden unbound
form and referencing those throughout the app instead. Another
advantage is that during development you can unhide the form and see
them.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com

 

[laavista]

The information "Some developers avoid Globals by placing controls on a
hidden unbound form and referencing those throughout the app instead." is an
interesting idea. I'm interested in doing this, but have a couple more
questions.

When you state that they "place the controls" on an unbound form, do you use
a text box and name it, and because the hidden form would be part of a
"collection", the control name for the text box would be available to any
procedure? If this correct, how do you specify the "type", e.g., long
integer?

Thanks for helping me with this.

 

[Armen Stein]

When you state that they "place the controls" on an unbound form, do you use
a text box and name it, and because the hidden form would be part of a
"collection", the control name for the text box would be available to any
procedure?

Yes, using syntax like Forms!MyGlobalForm.txtMyGlobalValue

If this correct, how do you specify the "type", e.g., long
integer?

You don't in the sense that you can in VBA. You can just hold the
values in regular text controls, knowing that they are being set and
read by your code, so they'll have the correct values in them. You
can always use a format and decimal places so that date or numeric
values display correctly to you during development.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com

 

[David W. Fenton]

You can just hold the
values in regular text controls, knowing that they are being set
and read by your code, so they'll have the correct values in them.
You can always use a format and decimal places so that date or
numeric values display correctly to you during development.

For what it's worth, I don't do this. I don't use any global
variables directly, but only via functions (or class modules) that
are sure to return a valid value no matter what. I also don't use
globals for passing information between forms, as I believe that
introduces an insufficiently robust outside dependency. Again, I'll
tend to use a class module for that kind of thing.

I try to make my functions self-healing, which means using a static
variable inside the function and initializing it the first time the
function is called. The logic for assigning the variable will depend
on the type of value being returned. If it's the kind of value that
is initialized at startup and not changed, then it will be relooked
up from whereever the value is stored. If it's a different kind of
variable, the logic will be specific to its purpose.

Obviously, a static variable is not going to be used for the kind of
global that is used to communicate between parts of an application,
but I don't use those. That kind of variable belongs as a property
of a class module, with proper Let/Get methods.

Were I to use the form method as a way of avoiding any volatility of
values stored there, I would likely *still* wrap it in functions and
class modules, and use static variables where appropriate (so it
would look it up from the form only the first time it was called). I
don't write apps that need that kind of protection from volatility,
not because my apps are error-free and never ever experience a code
reset, but because my apps are built to not need any such values in
the first place.

Globals are a shortcut, seems to me, and a very bad one because
there is no interface to control how they are set. That's why I use
class modules, because then I have a standard interface for
controlling the values.

 

[Armen Stein]

On 17 Apr 2009 22:38:29 GMT, "David W. Fenton"

Hi David,

I agree with all of your approaches. I was trying to provide a
simpler answer to the OP, but your points are valid.

We also generally avoid the use of Globals, except when they're
wrapped in a function or class module that auto-reloads them from a
table, calculation or wherever, much as you describe. Then we get
the speed of the global with some robustness too.

But for developers that aren't completely familiar with class module
programming, storing a few values on a persistent hidden form will
work just fine also.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com

 

[UpRider]

If you are using Access2007, check out TempVars. The values are globally
available and they do not lose their value if the program breaks.
However, there is NO explicit name checking, so your spelling must be
correct.
Interestingly, TempVars work even with AC2003 format DBs if you're using
Office 2007 Access.

UpRider

 

[laavista]

David, I found this very informative. Thanks!

For what it's worth, I don't do this. I don't use any global
variables directly, but only via functions (or class modules) that
are sure to return a valid value no matter what. I also don't use
globals for passing information between forms, as I believe that
introduces an insufficiently robust outside dependency. Again, I'll
tend to use a class module for that kind of thing.

I try to make my functions self-healing, which means using a static
variable inside the function and initializing it the first time the
function is called. The logic for assigning the variable will depend
on the type of value being returned. If it's the kind of value that
is initialized at startup and not changed, then it will be relooked
up from whereever the value is stored. If it's a different kind of
variable, the logic will be specific to its purpose.

Obviously, a static variable is not going to be used for the kind of
global that is used to communicate between parts of an application,
but I don't use those. That kind of variable belongs as a property
of a class module, with proper Let/Get methods.

Were I to use the form method as a way of avoiding any volatility of
values stored there, I would likely *still* wrap it in functions and
class modules, and use static variables where appropriate (so it
would look it up from the form only the first time it was called). I
don't write apps that need that kind of protection from volatility,
not because my apps are error-free and never ever experience a code
reset, but because my apps are built to not need any such values in
the first place.

Globals are a shortcut, seems to me, and a very bad one because
there is no interface to control how they are set. That's why I use
class modules, because then I have a standard interface for
controlling the values.

 

[laavista]

Armen, thanks for taking the time to explain this. I really appreciate it!

 

[laavista]

I will check out the TempVars (I am using Access2007). Thank you!