[AccessD] Framework Discussion - SysVars

SV as demoed is nothing more than a wrapper to the function in the class.
In a live system the SysVar class cannot go out of scope since it is global.
If the class is being terminated, you want to find and fix that, not just
reinstantiate it.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Robert Gracie
Sent: Monday, March 22, 2004 5:10 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Framework Discussion - SysVars



 John,

 No save guards on the SV call, say if the class has, for whatever reason,
gone out of scope?


Robert Gracie
www.servicexp.com


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby
Sent: Sunday, March 21, 2004 11:37 PM
To: AccessD
Subject: [AccessD] Framework Discussion - SysVars


The following is a discussion of Sysvars.  The demo file can be downloaded
from my site.  I have begun deleting older MDBs out of the zip file to slim
it back down since the original ZIPs are out there for the demos for the
earlier documents.  There is a form in the V5 mdb for demoing the SysVar
system in that MDB.
SNIP
'
Function SV(strSVName As String, Optional strSVFld As String =
"SV_VarValue") As Variant
On Error GoTo Err_SV
    Select Case strSVFld
    Case "SV_VarValue"
        SV = mcolSysVars(strSVName).Value()
    Case "SV_Memo"
        SV = mcolSysVars(strSVName).Memo()
    Case "SV_UserEditable"
        SV = mcolSysVars(strSVName).UserEditable()
    Case "SV_AllowOverride"
        SV = mcolSysVars(strSVName).AllowOverride()
    Case Else
    End Select
Exit_SV:
Exit Function
Err_SV:
        MsgBox Err.Description, , "Error in Function clsSysVars.SV"
        Resume Exit_SV
    Resume 0    '.FOR TROUBLESHOOTING
End Function

Summary
The SysVar system is most logically broken down into three classes, one is
the Service Class itself clsSysVars.  This is the class that the developer
interfaces with directly.  This class then uses clsSysVarsTbl instances to
read the data out of one or more SysVar tables, loading the data itself into
clsSysVar instances which are saved in a collection directly in the Service
Class.  clsSysVars then has public wrapper methods that pass requests to
refresh the SysVars and read SysVar values out of the clsSysVar class
instances.

Of course this could have been implemented differently; in fact my first
SysVar system used a single class which “did it all”.  It was ugly however,
and I think a three class “system” implementing SysVars is an easier to
understand way to implement it.  Each of the three classes has its own job
to do.  ClsSysVars uses clsSysVarsTbl to read out the data into clsSysVar
instances.  clsSysVars manages the process, setting up and tearing down all
the child classes, and wrapping requests for the child class methods to pass
along the requests for data or services.

SysVars will be used throughout the Framework to allow us to select from two
or more possible behaviors.  The table in the Framework will hold the
default values to program default behaviors, but the table in the FE itself
will be able to override the default values to change behaviors as needed in
that specific FE or application.  In the next article we will see SysVars
used to do exactly that.






John W. Colby
www.ColbyConsulting.com


--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com