Does custom form property get reset?

[TD]

I've read several posts here that say global variables are reset
whenever an unhandled error occurs. I want to use a custom form
property instead of a global variable to store a boolean value. My
question is does a custom form property get reset also? Was also
wondering if there is any reason one would ever use a global variable
since the consensus seems to be to never use global variables?

[Allen Browne]

How about a simple unbound check box on your form to hold the value while
the form is open, even if the variables are reset? (Make sure you set its
Default Value to False so it opens as unchecked.)

There are cases where global variables are needed to get around other
limitations. They can be helpful when you need to pass more information than
the built-in events allow. For example, you might OpenReport with a
WhereCondition, and you need the report to print an English description of
the way it is filtered. In Access 2000 and earlier versions, there was no
way to pass this extra argument to the report, so you need a global variable
that you assign the description to before you OpenReport, and then you can
read the global variable and assign it to the text box on the report in the
Format event the Report Header section. (Access 2002 and 2003 do have an
OpenArgs you can use to pass this info the report.)

But your thinking is essentially on track: use global variables only when
you are stuck, and only for short-term stuff. If it is possible to use a
local variable and pass it from procudure to procedure, that is the
perferred approach.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"TD" <dl**@adsi-sc.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com...

I've read several posts here that say global variables are reset
whenever an unhandled error occurs. I want to use a custom form
property instead of a global variable to store a boolean value. My
question is does a custom form property get reset also? Was also
wondering if there is any reason one would ever use a global variable
since the consensus seems to be to never use global variables?

[Anthony England]

"TD" <dl**@adsi-sc.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com...

I've read several posts here that say global variables are reset
whenever an unhandled error occurs. I want to use a custom form
property instead of a global variable to store a boolean value. My
question is does a custom form property get reset also? Was also
wondering if there is any reason one would ever use a global variable
since the consensus seems to be to never use global variables?

People use global variables because they are the easiest and quickest
(although not the most reliable) way to get the job done. They are easy
because you dimension them once and then can use them throughout the
application, and they are quick because they are held in memory and the
application does not need to read from or write to the disk in order to
retrieve and save them.

The big disadvantage is that, as you point out, they can get re-set with
un-handled errors. They are also open to being changed by any bit of code
in your application which you might have overlooked meaning that bugs can be
hard to track down.

So could you still use them? Well yes. Provided you are cautious about
their use, have ruled out other possibilities and ensure that use the
shortest possible span between setting them and retrieving the values.
Versions of Access prior to XP did not allow an OpenArgs argument to open
reports and so here you might set a global variable, open the report and let
the report's coding pick it the value of the variable. Provided you are
sensible about your coding, this is, in my opinion, reliable and acceptable.

So back to your question. Can the form's properties be reset? No, not
accidentally by unhandled errors but if your database is secured with
user-level security you may need to consider who can alter any custom
properties. You are also storing the setting with database whereas in some
circumstances it may be better to store the settings with the username in a
back-end table. So in a multi-user setting, a user could logon at any
machine and retrieve his/her settings.

In general, I would prefer to store app settings in a table and if I thought
that reading/writing would cause speed issues, then implement a way to load
them up at the start and save them back at the end.