By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,677 Members | 1,890 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,677 IT Pros & Developers. It's quick & easy.

Are static variables useful for replacing global variables?

P: n/a
About a year ago there was a thread about the use of global variables
in A97:

http://groups.google.com/group/comp....dc837a5aeb6157
>From the PDC 2005 presentation TLNL04 - Tips & Tricks: C++ Optimization
Best Practices by Kang Su Gatlin, casual mention was made about using
static variables as an alternative to using global variables. This
caused me to think of the following:

'-----Begin module code
Public Function MyGlobal(Optional SetValue As Variant) As Variant
Static varTemp As Variant

If Not IsMissing(SetValue) Then
varTemp = SetValue
MyGlobal = SetValue
Exit Function
Else
MyGlobal = varTemp
End If
End Function
'-----End module code

Supplying a value sets it and not supplying a value retrieves the last
set value. When no value was set, the function call returned an empty
string.

'-----Begin code behind form
Option Compare Database
Option Explicit

Dim varTemp As Variant

Private Sub cmdTest_Click()
Dim strSQL As String

strSQL = Nz(MyGlobal(), "It's Null.")
MsgBox (strSQL)
varTemp = MyGlobal(Null)
strSQL = Nz(varTemp, "It's Null.")
MsgBox (strSQL)
varTemp = MyGlobal("SELECT * FROM MyTable;")
strSQL = Nz(varTemp, "It's Null.")
MsgBox (strSQL)
End Sub

Private Sub Form_Load()
varTemp = MyGlobal("SELECT * FROM MyTable;")
End Sub
'-----End code behind form

It seems to work the way I expect. It also retained its value after I
forced an unhandled error. I also tried:

varTemp = MyGlobal(Array("1", "2", "3"))
strSQL = Nz(varTemp(1), "It's Null.")
MsgBox(strSQL) =2

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?

James A. Fortune
CD********@FortuneJames.com

Nov 14 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
>
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

Nov 14 '06 #2

P: n/a
Albert D. Kallal wrote:

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.
Based on your comments I did some testing of a more rigorous nature and
discovered that the static values do reset as you suggest. That sinks
the idea. I take it you didn't like my idea in the other thread of
using a local table to hold global values either? I value your
comments, but please count to 10 before answering.

James A. Fortune
CD********@FortuneJames.com

Nov 14 '06 #3

P: n/a
CD********@FortuneJames.com wrote:
Albert D. Kallal wrote:
>
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.

Based on your comments I did some testing of a more rigorous nature and
discovered that the static values do reset as you suggest. That sinks
the idea. I take it you didn't like my idea in the other thread of
using a local table to hold global values either? I value your
comments, but please count to 10 before answering.

James A. Fortune
CD********@FortuneJames.com
For many years I have used user set properties of the database or more
recently properties of access objects to hold a string representation
of any value that meets the needs one might associate with a global
variable. The coding for creating, getting and letting these properties
can be generalized to three public functions, reusable from application
to application. Their values are not reset on error. Their values live
on when the application is closed (do not have to be let or set again).
They are unique to the copy of the application being used, and by
extension to a user. They can be unique to a specific access object.

Nov 14 '06 #4

P: n/a
CD********@FortuneJames.com wrote in
news:11**********************@b28g2000cwb.googlegr oups.com:
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?
From the coder's perspective, there is no difference between the
type of static variable solution you gave and a property let/get.

I prefer to use static variables where there's some overhead
involved for setting the initial value, such as a User() function
that returns the Windows logon name. I use a plain old function and
a static string variable. If the static variable has Len() = 0, then
I look it up. Otherwise, I return the value of the static variable.

I hardly ever have any variables or the type that would be settable
in code. My only "globals" are things that are looked up (as
described above), or things that are constants. All other values are
stored in tables, derived from forms, or stored in data structures
like a class module.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Nov 14 '06 #5

P: n/a
David W. Fenton wrote:
I hardly ever have any variables or the type that would be settable
in code. My only "globals" are things that are looked up (as
described above), or things that are constants. All other values are
stored in tables, derived from forms, or stored in data structures
like a class module.
Thanks for your comments. When you say "derived from forms" do you
mean form instances as in Terry Kreft's interface solution, values on a
hidden form, properties of the form object as in Lyle's solution, or
something else?

James A. Fortune
CD********@FortuneJames.com

Nov 14 '06 #6

P: n/a
I take it you didn't like my idea in the other thread of
using a local table to hold global values either?
Not a bad idea at all.
I value your
comments, but please count to 10 before answering.
Hum, I was hard to the point, but I MOST certainly apologize if I came
across un-binding, condescending, or even arrogant.

My comments in my post are just that...my point of view. I should be allowed
to speak freely, but if I came across harsh, or in any way nasty, then do
accept my sincere apologies.

As always, ones mileage will vary on these issues, and I am *always* open to
debate here.....

I can really only speak out how my "creed" and view of development ideals
goes. My views are ceratnly not a the end all, or be all, but just the way I
see things...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
Nov 15 '06 #7

P: n/a
CD********@FortuneJames.com wrote in
news:11*********************@m7g2000cwm.googlegrou ps.com:
David W. Fenton wrote:
>I hardly ever have any variables or the type that would be
settable in code. My only "globals" are things that are looked up
(as described above), or things that are constants. All other
values are stored in tables, derived from forms, or stored in
data structures like a class module.

Thanks for your comments. When you say "derived from forms" do
you mean form instances as in Terry Kreft's interface solution,
values on a hidden form, properties of the form object as in
Lyle's solution, or something else?
I don't use a hidden form as a data storage structure, no.

I mean that if you need to collect values in a form, you collect
them in a form. What you do with them then may depend on the
context, but for the most part, I'd think those things that are
appropriate for collecting on a form should be persisted in a table
if they should be persisted, or used immediately and then discarded.

The point is that there doesn't seem to me to be much point for
storing data in variables. Most people seem to me to use them as a
substitute for communicating directly with the source of the
information. That is, they use a form to set globals, and then use
them somewhere else. I don't think that transient data (i.e., data
that's not a constant or not persisted in a table) belongs in
variables at all, unless those are variables private to the context
in which they are used.

Basically, all I'm saying is that using globals to communicate
between Access objects is just a bad idea.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Nov 15 '06 #8

P: n/a
"Albert D. Kallal" <Pl*******************@msn.comwrote in
news:H4v6h.323754$R63.105628@pd7urf1no:
Hum, I was hard to the point, but I MOST certainly apologize if I
came across un-binding, condescending, or even arrogant.
You were none of those things. I don't get the sensitivity.

Of course, I'm not exactly a shrinking violet, myself...

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Nov 15 '06 #9

P: n/a
David W. Fenton wrote:
I don't use a hidden form as a data storage structure, no.

I mean that if you need to collect values in a form, you collect
them in a form. What you do with them then may depend on the
context, but for the most part, I'd think those things that are
appropriate for collecting on a form should be persisted in a table
if they should be persisted, or used immediately and then discarded.

The point is that there doesn't seem to me to be much point for
storing data in variables. Most people seem to me to use them as a
substitute for communicating directly with the source of the
information. That is, they use a form to set globals, and then use
them somewhere else. I don't think that transient data (i.e., data
that's not a constant or not persisted in a table) belongs in
variables at all, unless those are variables private to the context
in which they are used.

Basically, all I'm saying is that using globals to communicate
between Access objects is just a bad idea.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
I see. By "derived from forms" you mean the normal way we use forms.
I agree that using globals to communicate between Access objects is a
bad idea. I have tried to minimize their use in the past. I think
I'll plan to phase them out entirely and avoid them completely in new
code. I'll probably use a table, object properties or a class module.
Maybe I should try all the proposed techniques before deciding on which
ones I like.

James A. Fortune
CD********@FortuneJames.com

Nov 15 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.