[AccessD] Classes and development power

As many of you know I am a strong proponent of classes and further, of the
organization of classes into an active framework.  I just wanted to throw
out an example of the power of classes (and frameworks) for the group.  
 
I have designed a (bound form) framework for use in building my
applications.  One of the classes is dclsFrm which is a class for handling
the form object.  Each form which needs one is provided an instance of this
class.  This class does many things, but one of the things it does is scan
the form looking for controls which have classes.  Controls such as text
boxes, combos, radio buttons, command buttons each have a class which I have
designed, and an instance of these control classes is automatically loaded
by the control scanner in dclsFrm.
 
Long ago I realized the concept of dependent objects, and in fact we have
seen this subject surface very recently in this forum.  A combo changes, and
another combo needs to be requeried because it "is dependent upon" the combo
that changed.  In my dclsCtlCbo (the combo control class) there is a
variable for a dependent objects class which I will call mclsDepObj.  
 
Private mclsDepObj As clsDepObjs            'dimensions a dependent object
class

There is a method of dclsCtlCbo which takes a paramArray (a very useful
construct) which essentially allows me to feed in as many objects as I wish
in one call to the function.  I call the function DependentSet.
 
'
'Many objects can have other objects dependent on it, which need to be
requeried
'if the parent object is requeried.  I call these "chained" or "dependent"
objects.
'
'A combo may be used as a filter for another combo, i.e. it may have a
dependent combo
'assigned to it.  This function allows the developer to assign an object
that is dependent on this one.
'Whenever this object is re-queried (using the re-query function in this
class), the dependent
'objects will then be re-queried.
'
Public Function DependentSet(ParamArray objs() As Variant)
On Error GoTo Err_DependentSet
Dim obj As Variant
    'if the dependent object class doesn't exist, instantiate it
    If mclsDepObj Is Nothing Then
        Set mclsDepObj = New clsDepObjs
        mclsDepObj.Init Me
    End If
    For Each obj In objs()
        Set mclsDepObj.DependentSet = obj
    Next obj
Exit_DependentSet:
    On Error Resume Next
Exit Function
Err_DependentSet:
        MsgBox err.Description, , "Error in Property Set dclsCtlCbo.
DependentSet"
        Resume Exit_DependentSet
    Resume 0    '.FOR TROUBLESHOOTING
End Function '

Thus by calling 
 
    clsMyCbo.DependentSet cboSomeDependentObject,
lstSomeOtherDependentObject
 
I can tell clsMyCbo that there are two "objects" which are dependent on that
combo, and if MyCbo changes, go requery all of the dependent objects.  I do
this in several places for a combo box, for example in the cblClick event
(which opens a form for editing the data behind the combo), in AfterUpdate
(which changes the value selected in the combo) etc.
 
Private Sub mcbo_AfterUpdate()
    mclsDepObj.ReQueryDependencies True  'Requery any dependent objects
end sub
 
In the case of dclsCtlCbo , I also have a simple Requery method which
requeries the associated combo for dclsCtlCbo, and then calls
mclsDepObj.requery to requery all of the dependent objects of this combo.
 
In a real life example, I have a form with three combos that are dependent
on another combo.  In the OnOpen of the form that contains these four
combos, I set up the dclsFrm to scan for all controls and load classes for
each control.  Once the form class has finished loading, I then tell one of
the combos that there are three other combos dependent on it.  Having done
this, whenever that parent combo changes, it triggers a requery of the
dependent combos automatically.
 
I can just hear people saying "holy smoke batman, that's a lot of
development work just to query a couple of combos.  That is true, but
consider that once the development work is done I can extend the concept to
every other control that can potentially have dependent objects.  Once I
design the clsDepObj, I can add one to a text box class so that if a text
box changes, it can automatically requery any dependent objects it may have.
Pretty much all data controls may have dependent objects.  Things like radio
buttons and check boxes, text boxes, lists, and combos can all have other
objects that, if the parent object changes, may need to cause its dependent
objects to requery to display different sets of data.  Having developed the
concept, I can now go into the classes for these other controls, add a
mclsDepObj to it and a requery method, and allow that control class to
control an entire list of dependent objects.  
 
Additionally the dependent objects can be ANYTHING that may need to "depend"
on a control, and has a requery method.  Real live Access lists and combo,
forms, other control classes etc.  This is very powerful stuff since I can
now look at this as a logical problem, "those objects over there need to
requery when this object changes" instead of "how do I program this (again,
and again, and again) "..  I simply feed a pointer to the object needing
requerying in to the class for the object which is the "parent" in the
requery chain.
 
Additionally, this can extend way down a chain.  A combo may cause a pair of
lists to requery.  Those lists may need to cause 3 different combos to
requery.  Those combos...
 
As long as I know "this object 'depends' on that object, I can just "feed
them in" as the form opens, and then the requery always happens, every time.
And if some unforeseen circumstance calls for a requery of one of those
objects, the class has a requery I can call which causes that specific
object to requery, then requeries all of its dependent objects, child,
grandchild on down.  Automatically.
 
Classes are a powerful thing.  Frameworks leverage classes to create a whole
new level of functionality.
 
Think about being able to code:
 
    clsMyCbo.DependentSet cboSomeDependentObject,
lstSomeOtherDependentObject, frmSomeDependentForm
 
and have all three of those objects requery automatically if MyCbo changes.
That's what I do.
 
John W. Colby
Colby Consulting
www.ColbyConsulting.com