[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
> ------------
>