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

A.D. Tejpal adtp at airtelmail.in
Fri Aug 10 03:38:12 CDT 2012


J.C.,

    Explanatory notes accompanying the sample db will have precise instructions for the prospective developer wishing to use his own single form as part of the split form arrangement. Following two lines are to be copied & pasted in declarations section of his form's module:

' Code in form's module
' Declarations section
'===============
Public Event EvFilter()
Public Event EvSearchDone(fm As Access.Form, AbsPos As Long)
'===============

    The following statement is to be inserted by him after any code block affecting form's filter state (This event will get detected in integrated wrapper class so as to enforce updating of recordset for datasheet portion):
'===============
RaiseEvent EvFilter
'===============

    The following statement is to be inserted by him after any code block involving search action (This event will get detected in integrated wrapper class and action taken to  ensure that the destination row gets displayed at mid-height of datasheet display window. It will take into account the latest window height depending upon the position of divider bar):
'===============
RaiseEvent EvSearchDone(Me, Me.Recordset.AbsolutePosition)
'===============

    Steps outlined above are demonstrated in the single form currently included in the sample db.

    Note:
    Apart from the above, DblClick & Enter events of each bound control on each of the two subforms (i.e. single form & datasheet portion) are used for hiding / un-hiding of columns and for appropriate color highlights (e.g. highlighting of current row as well as current cell in datasheet matching the active control in single form, apart from grey shading of single form controls where matching column in datasheet is in hidden state). These are taken care of automatically through a collection of control class objects whose parent property is set to the integrated wrapper class.

    The sample db is expected to get ready within a few days and I should be in a position to make it available for examination and ready reference.

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

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


  OK, I understand.  However any functionality handled in the custom class has to be known about in  advance.  The user of the "single form" cannot simply raise a new event in the form and expect the wrapper class to do something with it.  

  You are discussing the single form subform raising an event and causing the single form subform class to do something with that event.  What kind of event are you thinking about and what does the wrapper class do with these events?

  In the end, if you truly need a custom event in a standard form class to be sunk in a custom form class then you do indeed have to use the dim statement you first discussed to handle those events. 

  I am just not getting why you would be processing and raising such events in the standard form class to begin with.  The standard form class is for the use of the 3rd party designer, the form wrapper is for your functionality.  You need to specify an interface between your "single form" wrapper and the rest of the system.

  Keep feeding back your interface between the three pieces.  This is fascinating.

  John W. Colby
  Colby Consulting


More information about the AccessD mailing list