[AccessD] SysVars - was: Just in Time (off shoot of Can't open any more databases) -Thank you

John Colby jcolby at colbyconsulting.com
Sun Oct 5 21:16:35 CDT 2003


David,

Yes, the short load time as the tab is clicked on is simply the result of
not suffering that load time when the form first opens.  Either way the user
has to wait, up front or if they use a tab.

As for the Sysvars...

As the list old-timers know, I use a framework to speed my development time.
I have a class for each control that Access offers, which means I have a
class for the tab control, the subform control, the combo, list text box
etc.  And of course all of these control / form classes sink the events that
the control generates so that the class handles all generic event
processing - Withevents.  In addition I have other   classes such as a
SysVar class, which BTW you can find the basis of in the articles I wrote
for Database Advisors.

My tab control is what implements the JIT functionality for me.  IOW, the
tab class sinks the click event.  It determines if the user has just moved
to another tab, and if so it asks the parent form class if it is supposed to
use JIT - in fact it asks this at class load time.  The parent form has
loaded a Sysvar that says whether the application in general uses JIT, if
so, does it unload the subform as the user clicks off the tab.  However the
form can also look for and find SysVars SPECIFIC TO ITSELF that over-rides
the generic behavior.

IOW:

gJITSFrms		true	Global Just In Time SubFrms.  True = turn on JIT subforms,
False = turn them off.
gJITSFrmUnload	False	Global - True means unload JIT subforms when you tab
away from the tab.  False means once loaded, leave them loaded

However each form class (as it loads) looks for a sysvar with its name
embedded in the sysvar that over-rides the application wide preferences.

fJITSFrmUnloadtfrmEmployee	True	Local - True means FOR THIS FORM... unload
JIT subforms when you tab away from the tab.  False means once loaded, leave
them loaded

The g prefix in the sysvar name means that is the global behavior.  A f
prefix means that this behavior over-rides the global behavior only for the
form whose name is embedded in the SysVar.

This allows me to have a set of SysVars (a SysVar table) for my framework
that resides out in my framework library - called usystblFWSysVars.  That is
loaded first, and sets up the framework to work a "default" way.  IF I wish
to do so, I then add usystblFEFWSysVars - notice it is the same name with FE
embedded in there.  This table physically resides in the FE itself and I can
place any or all of the exact same name SysVars in this table but with a
value different from the one residing in the Framework library.  The load
order is Lib table then FE table, with the value in the FE table over-riding
(overwriting the value) from the framework library table if it exists in the
FE.  Same SysVar name, different value, loaded last, overrides the original.
Thus each FE can decide that the default functionality of the framework
should differ.

Of course the values specific to forms then override the values generic to
the FE or the framework.  The form specific values are searched for and
loaded BY THE FORM CLASS as the form loads, whereas the global SysVars, both
Framework and FE are loaded as the FE opens.

Because of the fact that the last value loaded into the class overwrites any
previous value loaded, and because the control / form class knows how to use
any generic sysvar but also look for the control or form name in the SysVar
name and use that to overwrite the generic SysVar, I can overload ANY
Sysvar, ANY behavior, on a case by case, form by form, control by control
basis.  Thus the app for company A can be completely generic, whereas the
App for company B can be customized to a T, all by doing nothing more than
throwing in a bunch of Sysvars into the FE sysvar table with object names
embedded in (at the end of) the SysVar name.

I have even toyed with the idea of setting up a USER LEVEL over-ride to
allow each user to decide whether they want the behavior, but I decided that
would be a dangerous thing to do.

OK, I've no doubt bored you to tears, but if you are thinking of using
SysVars, think about how to allow turning on / off functionality at the
library level.  Once you can do that, allow over-riding that in each app,
then once that works, allow over-riding that for any given control / form.

Works great, and makes application customization a snap.

John W. Colby
www.colbyconsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of David Fenton
Sent: Sunday, October 05, 2003 9:12 PM
To: accessd at databaseadvisors.com
Subject: [AccessD] RE: Just in Time (off shoot of Can't open any more
databases) -Thank you


Hello Charlotte and John,

You have both solved my hassles with the Can't load anymore databases.

I implemented JIT properly this time and it seems to have fixed the problem.
When the user clicks on a tab, the unbound subform takes about a second or
so to refresh itself after my code assigns the SourceObject, but the users
will have to live with that.

John, I like your idea of unloading (when the user clicks on a different
tab) the SourceObject from the subforms using a global sysvar and may also
implement that in my application.

I am grateful for you help.

Cheers
David Ô¿Ô¬
Brisbane Australia






More information about the AccessD mailing list