[AccessD] Framework Discussion - Just a teaser

The whole point of a framework is to allow the developer to add on things to
the functionality of a class or set of classes that may be useful to him or
his clients.  When I added dbl-click open form functionality the client
requested a visual clue for that functionality, i.e. something that would
tell their users that a specific combo had this functionality.  One way to
do this is to change the backcolor, forecolor, font etc of either the combo
or the label for the combo.

In order to get at the label I needed to know which label belonged to the
combo.  Notice that no controls have a "label" property with a pointer to
the label, but what every control has is a controls collection.  It happens
that the label is one of (or the only) control in that collection.  Thus
with the following code I could discover which label "belonged to" the combo
or other control:

'.Comments  :
'.Parameters:
'.Sets      :
'.Returns   :
'.Created by: John W. Colby
'.Created   : 6/17/02 11:22:19 AM
'
'Finds the label that "belongs to" any given control.
'
Function CtlLbl(ctlFindLbl As Control) As Label
On Error GoTo Err_CtlLbl
Dim ctl As Control
    For Each ctl In ctlFindLbl.Controls
        If ctl.ControlType = acLabel Then
            Set CtlLbl = ctl
        End If
    Next ctl
Exit_CtlLbl:
Exit Function
Err_CtlLbl:
    Select Case Err
    Case 0      '.insert Errors you wish to ignore here
        Resume Next
    Case Else   '.All other errors will trap
        Beep
        MsgBox Err.Description, , "Error in Function Utils.CtlLbl"
        Resume Exit_CtlLbl
    End Select
    Resume 0    '.FOR TROUBLESHOOTING
End Function

Having the ability to find the label, I added a label control into each
control class' header:

'
Private mlbl As Label               'The label associated with this control
'

And in the class' Init() a call to this function:

Function Init(ByRef robjParent As Object, lfrm As Form, lcbo As ComboBox)
'Pass in a pointer to a specific control
    Set mcbo = lcbo                     'Save that pointer to a private
variable here in the class
    Set mlbl = CtlLbl(mcbo)             'Find the combo's label if any
end function

Now that I have a pointer to the label I can manipulate it easily and
quickly in any manner I wish.  Thus in the combo class function that
programs NotInListData, if the lblnUseDblClick parameter is passed in I set
the backcolor and backstyle properties so that it changes color:

Function NotInListData(Optional strTbl As String = "", _
                        Optional strFld As String = "", _
                        Optional strForm As String = "", _
                        Optional lblnUseDblClick As Variant, _
                        Optional lblnUseNotInList As Variant)
    If Not IsEmpty(lblnUseDblClick) Then
        mblnUseDblClick = lblnUseDblClick
        If mblnUseDblClick Then
            mlbl.BackColor = 16744448
            mlbl.BackStyle = 1
        End If
    End If
end function

Understand that this is DEMO code.  Hardcoding "magic numbers" as the
16744448 back color would be known is strictly a no-no.  First of all, if
nothing else you would always specify a named constant so that it is crystal
clear what the number represents (blue) and also allow modifications as
needed.

In my framework I use a SysVar (which we will be getting into next) to set
the label back color for dblClick, and we will replace this code with SysVar
driven code in the next iteration.  Using a SysVar, if the SysVar is zero
then don't perform a backcolor change, else set the backcolor to the color
specified.  The default for the framework is set to 0 (don't do a backcolor
change) but in the FE the FESysVar table can override that default and turn
on backcolor changes for the dblClick combos FOR THAT APPLICATION.

This is precisely where a framework begins to shine.  Can this be done
without a Framework?  Of course it can.  You can do the same things in a
simple library, or even just hardcoding this stuff in forms somewhere (YUK).
But with a Framework the behavior is there throughout the application, can
be turned on/off with a simple switch, and can even be overridden for
specific instances, wither user preferences, client preferences, form by
form etc.

Handy stuff.

To see this code in action download the demo from my site and open the
frmPeopleV4.  Notice that the HairColor, EyeColor and City combos have a
blue label.  If you double click on them a form opens to allow adding data
to the list.  Notice that the other combos do not have double-click enabled
and their labels do not have a blue back color.

I am not advocating this specific behavior, please don't harass me with how
silly it is.  I am simply demonstrating that with a framework this kind of
functionality can be programmed one time and used forever.  It will be
available for any combo anywhere throughout the application, it simply has
to be enabled by whatever mechanism causes the behavior to appear.  In this
case it has to have a parameter set true (lblnUseNotInList) AND (in the
future) it has to have a SysVar set that "switches on" the behavior.

John W. Colby
www.ColbyConsulting.com