Preserving the Value of a Variable

Access 2016:

In a module called "basPublicVariables"  I create a variable:  "Public XYZ as Boolean"

Using a Form I assign a value to XYZ.

When I go to another form, that Variable has lost its value, or reverted to zero or etc.....

QUESTION: How do I preserve the value of a Variable from one form to the next?
Biggles1Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

MacroShadowCommented:
Module basPublicVariables should look like this:

Option Explicit ' not required but highly recommended

Public XYZ as Boolean

Open in new window


Then when XYZ is set from within a form it should retain its value.
0
Biggles1Author Commented:
Thanks MacroShadow for the prompt reply.

Actually both conditions, Option Explicit and Public XYZ as Boolean are implemented.

The variable XYZ (which I set as True and then also as -1) reverts back to 0 or blank!

Is that a quirk of Access 2016?  The same code worked fine in Access 2010 and before that in Access 2003.

Biggles1
0
MacroShadowCommented:
Can you upload a proof of concept?
0
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

Fabrice LambertFabrice LambertCommented:
It sound like there is a variable shadowing fenomenon.
Check if there isn't a variable with the same name and / or lower scope somewhere.

Overall, it is a bad idea to use global variables, this is usually a sign of bad design.
There is probably another way to achieve what you want, like defining a property within your forms.
0
Biggles1Author Commented:
If there were a variable of the same name would I not get a compile error?

Public Variables are the only way I could think of to preserve a value across different forms.
0
Mark EdwardsChief Technology OfficerCommented:
I agree with Fabrice.  There must be something somewhere that is changing your XYZ variable value.
Keep in mind you can have a global XYZ and a module-level or procedure-level XYZ with different values.
Just checking what the value of XYZ is leaves it to Access to decide which is the default variable to check.

Try declaring your global XYZ as "Public g_XYZ As Boolean" and see if anything changes.
It's always a good idea to prefix a variable with the level of the variable:
"g_" for global-level
"m_" for module-level
no prefix for procedure-level

Take a look at that and see if you're overlapping things...
0
Mark EdwardsChief Technology OfficerCommented:
public variables are the easiest way to make a variable visible to any code in your app.  There are other ways such as saving the values in a table or application property and using your own functions to set/get the value.
0
Fabrice LambertFabrice LambertCommented:
If there were a variable of the same name would I not get a compile error?
Only if the variables have the same scope.
Consider the following code:
    '// define a global variable
Public myVariable As string

Public Function myFunction() as string
        '// define a local variable
    Dim myVariable As String
    myVariable = "cat"
    myFunction = myVariable
End Function

Open in new window

When the function is run, because it define a local variable with the same name as the global one, but with a lower scope, both variables can co-exist.
But, within the function, you are refering to the local variable, the global one is masked.

Public Variables are the only way I could think of to preserve a value across different forms
When opening a form, the docmd.openform provide an optional argument named OpenArgs that you can use to pass additional parameters to a form.
Within the form, these additional parameters can be retrieved from the OpenArgs property.

Also, keep in mind that forms are classes.
You can define private variables as well as properties or methods.
0
Fabrice LambertFabrice LambertCommented:
It's always a good idea to prefix a variable with the level of the variable
Also called hungarian notation, I do not recommend this.
Should you need, for whatever reason, to change the scope of a variable, the nighmare begin, because you need to change its name accordingly everywhere, else  your variable name will loose its meaning. This is highly error prone.
public variables are the easiest way to make a variable visible to any code in your app.
Erm ... easy or lazy ?
Global variables must be avoided, unless you have a very good reason.
Keep in mind that every functions / procédures / classes / forms can read and write global variables without restriction, nor security.
Call a function, and go figure why your global variables no longer have the values you expect, or go figure why a function no longer behave correctly.
Plus, should an unhandled error occure, your project will collapse, and all your global variables will vanish.
0
Mark EdwardsChief Technology OfficerCommented:
The purpose of hungarian notation is to prevent confusion and nightmares.  Since when does using the same name for a variable at any scope make it any less a problem?  Plus, running a code text replacement to replace "g_XYZ" with "m_XYZ" or "XYZ" if you want to change scope takes a few seconds.  If you want to have to try and remember the scope of your variables all through development and maintenance, then by all means just call them whatever you want with no clue as to what their scope is.  Now that's what I call dangerous....

However, if you use other means to set and retrieve single values from stored means, then there is no need for Hungarian notation as you get your value from that means, whatever scope or name you call it.

Developers experience the highest number of situations where the value of global variables are lost, since they are always testing and playing with their code in break mode.  Plus, unhandled errors which forces a user to click the "End" button - which kills all global variables, among other things - is the biggest reason for users losing global variables, and is more of a symptom of poor error handling by the developer.  When developers are under a lot of pressure to "wrap it up", they have their own methods for getting something put together that works with as few problems as possible, given the time available to work on it.

If anything, this discussion shows how a lot of ways of doing things is up to the whims and personal experiences of the developer.  It would be interesting to see what any of the other experts think about this.
0
Fabrice LambertFabrice LambertCommented:
Plus, running a code text replacement to replace "g_XYZ" with "m_XYZ" or "XYZ" if you want to change scope takes a few seconds.
I'm sorry, but this is exactly why I do not recommend hungarian notation.

With big projects, devs tend to do a search and replace on the entire project, then they sudenly wonder why the project becomes full of weird bugs. All this because some variable names were replaced while they were supposed to remain untouched.
0
Mark EdwardsChief Technology OfficerCommented:
"devs tend to do a search and replace on the entire project, then they sudenly wonder why the project becomes full of weird bugs"

As a developer, you have to be somewhat careful and knowledgeable of what you are doing to make sure you don't do something unintentionally.  You can't prevent stupidity.... no matter what technique you use.
0
Biggles1Author Commented:
Based on various remarks by Mark and Fabrice, I did some trial and error "detective" work and stumbled on the answer (you know, if you try enough crazy stuff eventually something is going to fail so dramatically that it will point to the answer).  The problem (duh) was the the control (in this case a CheckMark) had the same name as the Variable!  Fixed this and it's working now.  Thanks Guys very informative comments and I learned stuff I did not know.  Occasionally, you can fix stupid.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Biggles1Author Commented:
I guess this closes the question?  I could not find a specific command button to say that.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Remote Access

From novice to tech pro — start learning today.