[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

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

On 8/9/2012 4:28 AM, A.D. Tejpal wrote:
> 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
> ------------