One of my forms has a great deal of internal state information,
most of it loaded from a table when the form opens. If I reset
during debug, the state is lost, and the form no longer works.
It is not self-healing: I am forced to close and re-open the form.
What would be your approach to this situation?
(david)
"David W. Fenton" <dXXXfenton@bway.net.invalid> wrote in message
news:Xns96ECA1E07B1B2dfentonbwaynetinvali@24.168.1 28.90...[color=blue]
> MLH <CRCI@NorthState.net> wrote in
> news:tavnk11vrcctcc82sjgeusjil6ilf63n28@4ax.com:
>[color=green]
>> A97 Topic: If there is a way to preserve the values assigned to
>> global variables when an untrapped runtime error occurs? I don't
>> think there is, but I thought I'd ask.
>>
>> During development, I'm constantly running tests on imperfect
>> code. On of the cumbersome jobs encountered is reassigning global
>> vars their values after a close encounter with an untrapped
>> runtime error.
>>
>> Rather than writing a procedure to simply reassign them all with a
>> single bttn-clik, the way I've been doing it ever since Access 2.0
>> is by closing and then reopening the app. That gets cumbersome.
>> But its the only way I've ever known. Just wondering.[/color]
>
> First off, if your app uses lots of global variables, then there's
> probably something wrong with it.
>
> Global constants are a different thing -- those are fine, but they
> also don't get lost on reset because they are hardwired into the
> compiled p-code.
>
> You need to re-evaluate all the cases where you are using global
> variables and figure out if you can replace them with self-healing
> objets.
>
> For years, I used a global variable to store a reference to the
> current database for use in place of every declaration of Set db =
> CurrentDB(). But that wouldn't survive a code reset during
> development, so I started doing this:
>
> If dbGlobal Is Nothing Then Set dbGlobal = CurrentDB()
> Set rs = dbGlobal.OpenRecordset([SQL])
>
> If you replace the global variable with a function that returns the
> data type of the global variable, that function can "heal" itself:
>
> Function dbGlobal() As DAO.Database
> Static db As Database
>
> If db Is Nothing Then Set db = CurrentDB()
> dbGlobal = db
> End Function
>
> The way this works is that, with a STATIC variable, the first time
> it's called, it initializes the internal STATIC variable, and as
> long as there's not a code reset, just returns the value of the
> STATIC variable. If there's a code reset, the STATIC variable gets
> cleared and when the function is called it will be re-initialized.
>
> This principle can be applied to any number of global variables that
> are used to store application-wide data (such as form colors or any
> other application-specific data).
>
> Now, the problem is: where do you store the persistent data?
>
> Well, you can have a table or you can use custom properties of the
> MDB file. Why, then, not just look them up each time you use them?
> Because it's much slower to do a table lookup up or to find the
> value of a database custom property than it is to check a global
> variable or get the value from a public function.
>
> Now, as you can see, I'm limiting this to global variables that are
> used for storing global values that are permanent throughout a
> working session, and have only one value that is not changed after
> the variable is initialized.
>
> All global variables that change values at runtime SHOULD BE
> ENTIRELY ELIMINATED FROM AN APPLICATION.
>
> For passing data between forms, it's much better to *not* use global
> variables. I tend to use class modules for this, as simple data
> storage structures, because class modules can be self-initializing,
> and because they provide a single intermediate structure for
> mediating between runtime objects. That is, if you want form1 to get
> data from form2, a class module makes it much easier to manage.
> Form2 sets up the class module, and then form1 gets its data from
> the class module. This makes it much easier to get the same data
> from different forms, because the receiving form needs to know only
> about the class module -- it doesn't need to know anything at all
> about the source form.
>
> That's the idea behind using global variables for that purpose, but
> that has the downside of:
>
> 1. losing values on a code reset with no way to automatically
> re-initialize them.
>
> 2. values don't clear themselves when they are obsolete, so you
> could accidentally use data that was a different context.
>
> With a class module-based structure you initialize an instance of
> the class for the immediate purpose, populate its values, use the
> values in a different context, then when done, destroy the instance,
> thus clearing stored values.
>
> The key issue here is that you just need to get away from using
> global variables as much as possible. If you do that, you end up
> with better code and less annoyance during coding.
>
> --
> David W. Fenton
http://www.bway.net/~dfenton
> dfenton at bway dot net
http://www.bway.net/~dfassoc[/color]
