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

JC,

    It so happens that hooking of events is not the issue here. In the class module, setting required event properties to "[Event Procedure]" is a fundamental step, without which the event won't fire. That aspect is always taken care of.

    My question refers to a form where a certain event has been raised via RaiseEvent statement. Let us say a filter and / or search action is carried out through a combination of controls like option groups / combo boxes / text boxes / check boxes etc. On successful filter / search, event EvFilterSearch() is raised via RaiseEvent statement in form's module. In the wrapper class, excessive cluttering up can be avoided by simply trapping EvFilterSearch() - rather than setting up WithEvents pointers to individual controls.

    In the wrapper class, if the pointer to such a form (named MyForm) is declared as Access.Form, and an attempt made to hook the events after due instantiation, it will be found that there is no property matching EvFilterSearch event. This event is also found missing from the drop down list at top right of VBA window, which shows all built-in events like Load / Current etc, including those for which explicit hooking by setting event property to "[Event Procedure]" has not been done. Of course, unless hooked, code in stubs for un-hooked events won't execute.

    On the other hand, if the pointer is declared as Form_MyForm (instead of Access.Form), EvFilterSearch event gets displayed in the drop down list at top right of VBA window. Built-in events like Load / Current do not get displayed in this list. Moreover, no explicit hooking for this custom event is needed. In fact you can't do it, as the item is still found missing from properties list of the pointer (interestingly, the properties list does include the built-in events). Code in stub generated for this event gets executed smoothly.

    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.

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

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


  AD,

  When I create a class I create a constructor mInit.  In the case of a form class I use something like:

  Private Const mstrEventProcedure = "[Event Procedure]"  'A constant to hold the string [Event Procedure]

  private WithEvents mfrm as dao.form

  function mInit(frm as dao.form)
  set mfrm = frm
  mfrm.AfterUpdate = mstrEventProcedure
           mfrm.BeforeInsert = mstrEventProcedure
           mfrm.OnDelete = mstrEventProcedure
           mfrm.OnCurrent = mstrEventProcedure
           mfrm.OnUnload = mstrEventProcedure
           mfrm.BeforeUpdate = mstrEventProcedure
           mfrm.OnClose = mstrEventProcedure
  end function

  Having done that all of the built-in events of the form are exposed.  However in order to cause the 
  events to actually fire the event property of the form object has to be set to the actual text

  [Event Procedure]

  If the property does not have this text in it then even if you click or whatever the event does not 
  fire so the code in the event sink does not run.  If you think about it, this allows you to turn on 
  and off events firing by simply inserting or deleting this string from the event that you siwh to 
  control in this manner.

  Having done all of this, you can now define the event sinks in your custom class which you want to sink.

  BTW all of this is true for other controls such as a text box, combo etc.

  The last thing that you need to know is that if you have an event sink in your custom class and you 
  have an event in the form's class directly, the order that the two event sinks run is determined by 
  the version of access!  Which REALLLLLY sucks since now your code operates differently depending on 
  the version of Access that it runs under.

  Gotta love Microsoft.  Give them credit though, they got it wrong the first time and made the 
  painful decision to fix the issue in later versions even though it broke things.

  I call these custom classes "wrappers" since they "wrap" the object which we wish to manipulate and 
  allow us to sink the specific events that we care about.

  BTW all of this is documented in a ton of emails I sent the group years ago, which purported to 
  teach class programming in Access.

  BTW I have never dimensioned a form as you do below

   > Private WithEvents mfm As Form_MyForm

  so I don't know what events it sources like this.  It never occurred to do that but I would have 
  thought that it would be the same events as a normal form, unless of course you are raising your own 
  events in that form's class.  We can raise events in our custom class of course so you can likewise 
  raise your own events in the form's class directly.

  If you simply create a wrapper class for the form and raise the events in there then you have one 
  place to do all that stuff.  Not sure if that meets your needs of course.

  John W. Colby
  Colby Consulting

  Reality is what refuses to go away
  when you do not believe in it

  On 8/8/2012 7:43 AM, A.D. Tejpal wrote:
  >      It is observed that for trapping custom events raised in a form, WithEvents pointer in a new class needs to be declared as that form's class object, as per sample statement below:
  >
  > ' Sample code in class module
  > '==============================
  > Private WithEvents mfm As Form_MyForm
  > '==============================
  >
  >      However, the resulting object does not expose built-in events of the form (like Load, Current etc).
  >
  >      On the other hand, declaring it as Access.Form makes available all the normal events of a form but not the custom events.
  >
  >      For getting access to both sets of events, it is found necessary to set up two separate pointers, one as Access.Form and the other as Form_MyForm.
  >
  >      Could there be a better course of action?
  >
  > Best wishes,
  > A.D. Tejpal
  > ------------