[AccessD] Trapping Events In A Class (custom events as well as built-in)

J.C.,

    Thanks for the confirmation.

    I agree - it would normally be preferable to handle everything in the 
wrapper class itself. However, this particular case seems to merit a 
modified approach in the context of proposed sample db for simulated split 
form.

    The underlying idea is to provide a basic arrangement comprising of main 
form with two subform controls. The bottom control has a datasheet template 
as its source object, while the single form meant to serve as source object 
for top subform control can be designed by any developer wishing to adapt 
this sample. The person would have  complete freedom regarding the design, 
VBA code and logic used in such a form's module.

    When such a form (single form view), developed by third party, is 
assigned as source object for top subform control, everything else needed 
for display and functioning of split form, is planned to be handled by an 
integrated class that has WithEvents pointers to the main form as well as 
the two subforms, ensuring automatic generation of datasheet matching the 
current status of single form, as well as proper synchronization between the 
two.

    It is in this context that some nominal code is added to single form's 
module (while retaining its existing code intact) for raising custom events, 
destined for detection in the integrated class. The logic behind raising of 
such events remains native to the single form, in keeping with its 
individual design by third party. Object pointer for this class is 
instantiated in main form's open event.

Best wishes,
A.D. Tejpal
------------

----- Original Message ----- 
From: jwcolby
To: Access Developers discussion and problem solving
Sent: Thursday, August 09, 2012 01:07
Subject: Re: [AccessD] Trapping Events In A Class (custom events as well as 
built-in)

A.D.

 >Coming back to the original question, it would seem that for such a form, 
if both sets of events
(built-in as well as custom) are to be utilized in a wrapper class, setting 
up of two separate
pointers would be necessary.

It certainly does appear that way.  If my class is going to sink such events 
I usually create
WithEvent pointers in the form wrapper for the control that will be raising 
the event and then
handle it in that form wrapper class.  What you are essentially saying is 
that you want the wrapper
class to handle the event in the end so why not just sink the event directly 
in the form wrapper class?

Basically I remove all of that stuff from the form itself and place it in 
the form wrapper.  Now I
either pass in the control in my wrapper mInit() method or I reach up into 
the form and get a
pointer to those controls.  I always pass a pointer to the form to my 
wrapper class and store it so
getting stuff from the form is trivial.

In fact if the control itself has any other functionality it needs to handle 
I will create a wrapper
for the control itself as well.  Combos and text boxes are examples of such 
controls.

As an example in my framework I have a mFindControls method which literally 
iterates the form's
controls collection and attempts to create a wrapper for each control found, 
the type of which is
called out in a big case statement.  I have prewritten wrapper classes for 
some but hardly all of
the various types of controls.  However if down the road I need a new 
wrapper class for a control
type not yet covered, I write it and hook it into this case statement.  This 
is how my framework
evolved over time.

I use naming conventions to trigger loading variations of control wrappers 
as needed.  As an example
I will have a txtPKID text box bound to my PKID (always a long int right!) 
and when found I plug
that into a dimensioned variable in the class header (no wrapper at all).  I 
use that control to
tell the form wrapper what PKID the form is currently on in case I need to 
sync a combo box or whatever.

OTOH I have a class which I load for text boxes not matching my naming 
conventions.  This allows me
to (for example) look at the data type of the field that the text box is 
bound to (this is possible
with DAO) and set a standardized date/time format in the text box's format 
property if the control
is bound to a date/time data type.

     For Each ctl In mfrm.Controls   'Find each control in the form's 
control collection
         With ctl
             On Error Resume Next
             If blnNoRecordset = False Then
                 intCtlDatatype = mrst.Fields(ctl.ControlSource).Type
             End If
On Error GoTo Err_mFindControls
             Select Case .ControlType    'Determine it's type
             Case acTextBox  'Find all text boxes and load class to change 
backcolor
                 '
                 'There can be two text boxes used for specific purposes.
                 'If they exist they will have specific names.
                 '
                 Select Case .name
                 '
                 'txtPKID is the control bound to the PK of the recordset
                 'and is used for finding records, the recordselector combo 
etc.
                 '
                 Case "txtPKID"
                     Set mtxtPKID = ctl
                 '
                 'txtParentPKID is bound to the parent form's PK in a 
subform
                 'and allows the framework to discover when the parent 
record changed
                 'so that objects in the subform can be requeried when the 
parent form
                 'changes from record to record
                 '
                 Case "txtFKParentID"
                     Set mtxtFKParentID = ctl
                     mstrFKFldName = mtxtFKParentID.ControlSource
                     On Error Resume Next
                     mlngParentPK = mtxtFKParentID.Value
                 Case Else
                     mcolClasses.Add New dclsCtlTxtBox, .name
                     mcolClasses(.name).mInit Me, mfrm, ctl, intCtlDatatype
                 End Select
             Case acSubform
                 mcolSubForms.Add New dclsCtlSFrm, .name
                 mcolSubForms(.name).mInit Me, mfrm, ctl
             Case acTabCtl   'tab pages are handled in the tab control
                 mcolTabs.Add New dclsCtlTab, .name
                 mcolTabs(.name).mInit Me, mfrm, ctl
             Case acOptionGroup
             Case acCheckBox
             Case acOptionButton
             Case acCommandButton
             Case acToggleButton
             Case acListBox
             Case acComboBox
                 If .name = "cboRecSel" Then
                     Set mdclsCtlCboRecSel = New dclsCtlCboRecSel
                     'mcolClasses.Add New dclsCtlCboRecSel, .Name
                     mdclsCtlCboRecSel.mInit Me, mfrm, ctl, mfrm!txtPKID, 
mblnUsesADO
                     'mdclsCtlCboRecSel.cGI.pIsADOFrm = mblnUsesADO
                 Else
                     Dim lclsCtlCbo As dclsCtlCbo
                     Set lclsCtlCbo = New dclsCtlCbo
                     lclsCtlCbo.mInit Me, mfrm, ctl, intCtlDatatype
                     lclsCtlCbo.cGI.pIsADOFrm = mblnUsesADO
                     mcolClasses.Add lclsCtlCbo, .name
'                    mcolClasses(.name).mInit Me, mfrm, ctl, intCtlDatatype
                 End If
             Case Else
             End Select

John W. Colby
Colby Consulting