[AccessD] MODIFY THE FORM CLASS TO LOAD THE NEW COMBO CLASS.

jwcolby jwcolby at colbyconsulting.com
Mon Feb 9 19:52:23 CST 2009



The next thing we have to do is tell the form how to load an instance of the clsCtlCbo for every 
combo in the form.  To do this we will use the scanner.

•	Open clsFrm.  Go down to ctlScanner.  Modify the case statement, case acComboBox as follows:

             Case acComboBox
                 Dim lclsCtlCbo As clsCtlCbo
                 Set lclsCtlCbo = New clsCtlCbo
                 lclsCtlCbo.mInit ctl
                 colCtls.Add lclsCtlCbo, ctl.Name
             Case acCommandButton

The Dim statement dimensions an instance of the new clsCtlCbo.  The Set statement creates an 
instance of that class.  The mInit statement callse sht class mInit(0 method passing in a pointer to 
the current control.  The  last statement stores the class instance in the collection colCtls, keyed 
on the control name.

•	Save the clsFrm.
•	Open the form.
•	Click into the combo control.  The GotFocus event should fire and display a message box.  Click 
out of the combo box.  The LostEvent event should fire and display a message box.
•	Type anything into the combo.  Since the combo isn’t bound to anything, nor in fact even loading 
anything, the text typed in will be accepted.  When you hit enter, the BeforeUpdate will fire and 
display a message box.  Then the AfterUpdate will fire, then the LostFocus will fire.

What we have demonstrated is that the form’s ctlScanner is in fact finding, loading and storing a 
class for the one combo on the form.  The events that we sink in the class are firing.  Good stuff.

•	Open the form in design view.
•	Add two more combo controls into the form.
•	Save the form and open the form again.  Click into each combo control in turn.
•	Notice that the GotFocus and LostFocue events fire for each combo in the form.

What we have demonstrated is that the scanner is loading an instance of clsCtlCbo for EVERY combo in 
the form, and that the events fire for every combo in the form.

This is the magic of a framework.  The form class is loaded for any form you desire.  The form class 
knows how to load classes for various controls.  The scanner loads the control classes and the 
control classes know how to do some specific thing(s) every time.  No more programming the combo to 
do that thing in for every combo in every form, it just does it.

Now what kinds of things might a combo control do?  How about store its old value in a log table 
every time the value changes?  How about turn a different back ground color when it gets the focus 
and back to its original color when the control loses the focus?  How about a double-click event 
that opens a form for entering new data into the list behind the combo?  How about requerying 
“dependent objects”, i.e. other combos or even subforms that will pull a different set of records 
depending on what the current value of this combo is?  How about moving to a specific record of the 
form if this is a record selector combo?

I call these things “behaviors” of an object.  If you can imagine it, you now have a place to store 
the code to make behaviors happen, and you have a method to cause every combo to perform that behavior.

I am going to stop now to allow you to absorb what you have learned.

-- 
John W. Colby
www.ColbyConsulting.com



More information about the AccessD mailing list