losing "Public" variables on error

[Drjay]

When our application starts up we load user preferences in a series of
"Public" variables and refer to them throughout the application. Whenever we
have an untrapped error all of these values are lost and so the application
doesen't know what to do.

Why does Access lose these values? Is there any way to prevent this?

 

[Rick Brandt]

When our application starts up we load user preferences in a series of
"Public" variables and refer to them throughout the application.
Whenever we have an untrapped error all of these values are lost and
so the application doesen't know what to do.

Why does Access lose these values? Is there any way to prevent this?

Known issue with MDB files. It does not happen with MDE files which is all I
distribute so I never have the problem. Of course I try to never have untrapped
errors either so even in an MDB it would be rare for me.

You can either...

Trap all your errors
Use an MDE
Switch to storing your values in controls on a hidden form

 

[Douglas J. Steele]

Realistically, you answered your own question: whenever you have an
untrapped error, the values are lost.

In general, using public variables is discouraged. What do the variables
represent? There's probably a better way of doing it.

 

[Dirk Goldgar]

When our application starts up we load user preferences in a series of
"Public" variables and refer to them throughout the application. Whenever
we
have an untrapped error all of these values are lost and so the
application
doesen't know what to do.

Why does Access lose these values? Is there any way to prevent this?

I'm afraid that's just the way it works -- values of public variables are
lost whenever there is an unhandled error. You can (a) ensure there are no
unhandled errors, or (b) put these values into controls on an unbound,
hidden form and refer to them from there -- then an unhandled error won't
clear them -- or (c) set them up as public properties, with Property Get
functions that reload them if the private, internal variable has lost its
value.

Or (d), some other possibility, but those are the ones that spring to mind.

 

[David W. Fenton]

Trap all your errors
Use an MDE
Switch to storing your values in controls on a hidden form

Or use self-healing functions and class modules that will
re-initialize themselves upon a code reset.

My philosophy is that public variables of whatever type should never
be used for any purpose except buffering data that is looked up from
somewhere. This would be configuration data, user name, and so forth
-- all things that can be easily re-initialized should the data be
zeroed out. Public variables should never be used for passing data
between Access objects. There are a number of better options for
that, including OpenArgs, reading the data directly from the other
object, or using a class module as a data structure for storing
numerous data points.

I tend to do the latter for report filtering, for instance, so that
all the reports depend on the same class module and do the filtering
specific to a particular report in the report's OnOpen event. The
class module is populated from various dialog forms specific to the
attributes being filtered. This makes everything independent of
everything else -- the class module doesn't have to know anything
about either the dialog forms or the reports, and the forms and
reports don't need to know anything about each other. The forms
interact with the class module instance, and the reports interact
with the class module instance.

I find this kind of approach very easy to work with in this context.

It's not so easy for other contexts, nor for simple operations, and
I don't always use it. But it certainly makes complicated projects
easy and maximizes code re-use.