[AccessD] Building a control class

AD,

>Interestingly, it is observed that code blocks with raised events sandwiched in-between, do get executed in the intended sequence. For example:, in the following case, control class objects of text box type respond to (B) after execution of code (A). Thereafter code (C) executes, followed by control class objects of combo box type responding to (D). Thereafter, code (E) executes.

What I was attempting to say is that if you pass in the form object 
itself (not its class clsFrm) and sink a form event (current as an 
example) inside of each control class, THEN that control class' event 
sink will only get control AFTER the clsFrm's native current event code 
completely processes, AND after any current event sink in code behind 
form as well for that matter.  Code Behind Form gets control FIRST, 
clsFrm's event sinks get control SECOND, and only when those two event 
sinks relinquish control will each control's class get control in the 
order instantiated. 

As you are discussing, if you raise an event in clsFrm, in the current 
event for the form object, AND you have passed in the clsFrm into each 
control class AND you have dimensioned its variable WithEvents AND you 
have sunk such an event in the control's class THEN of course the 
control will pass exactly as you indicate it would.

There are a huge variety of ways to pass control around using object 
events, raising your own events and event sinks.  In general the most 
useful and easily understood is simply a wrapped object's events being 
sunk in the wrapper, and a different scenario where several controls are 
passed in to a class and events sunk for the purpose of turning the set 
of controls into a related system.  I use both of these scenarios daily, 
and I use more offbeat scenarios occasionally.

Ages ago I created a system of a text box and a list box which emulates 
a combo box.  I created a list box that was a single line width in 
height. When the user starts to type in to the text box I dropped down 
the list box.  The user typing in the text box would "filter" down the 
list to a smalled and smaller set of values.  When the user left the 
list, the selected value was placed in the text box and the list popped 
back up again and became invisible.  There are things you can do in a 
list that you cannot do in a combo, for example multi-select as well as 
more easily reordering objects in the list. This "system" became a cross 
between a combo and a list with the best properties of both.  It 
certainly never replaced Access' combo and list controls, but it added 
functionality in specific cases where Access' controls didn't quite suffice.

Classes wrapping controls can enable you to make some cool "rules" systems.

BTW, using a "third party" class as an interface can get you back to a 
disentangled state.  One of the problems with having classes 
"understand" each other is simply that they begin to require an instance 
of the other class in order to function at all.  Testing the child 
requires the parent to be there.  In cases where I wanted classes that 
could USE each other but not REQUIRE each other, I use my message 
class.  The message class simply exists at the end of a pointer.  Anyone 
can call a method of the message class and send a message.  Classes can 
then grab a pointer to the message class, sink the message event, and 
start watching for messages.  One object uses the message class to send 
a message, the other listens for messages.  They can even talk back and 
forth.  However because they are disconnected, neither REQUIRES that the 
other exist.  They raise a message and if someone is listening it does 
something when it sees the message.  You can test the sender without the 
listener, and you can even test the listener simply by sending messages 
from the debug window or a simple test harness without the sender being 
instantiated.

Arthur has a scenario where he wants two forms to stay in sync.  If an 
order form changes to a different order, then a matching customer form 
finds and displays the matching customer.  Each form needs to be usable 
without the other being loaded, but IF the customer form is loaded, then 
it syncs to the order form.  A message class can provide the loose 
coupling to achieve this.

Again, these kinds of systems solve specific problems.  They are not 
about being the be all and end all of tools.

John W. Colby
www.ColbyConsulting.com



A.D.Tejpal wrote:
> John,
>
>     Your detailed clarifications on various points are most helpful. In actual implementation, I intend to give very high weightage to your recommendations. The intention of these postings is to look at various angles (somewhat akin to devils advocate), so as to derive the benefit of your experience and knowledge.
>
>     Interestingly, it is observed that code blocks with raised events sandwiched in-between, do get executed in the intended sequence. For example:, in the following case, control class objects of text box type respond to (B) after execution of code (A). Thereafter code (C) executes, followed by control class objects of combo box type responding to (D). Thereafter, code (E) executes.
>
> '====================================
> Private Sub mFrm_Current()
>
>     '<< Do Something >>        ' (A)
>
>     RaiseEvent FormCurrentForCombo(<< Arguments suiting Combo >>)    ' (B)
>     
>     '<< Do Something >>        ' (C)
>     
>     RaiseEvent FormCurrentForTxtBox(<< Arguments suiting TxtBox >>)    ' (D)
>
>     '<< Do Something >>        ' (E)
>
> End sub
> '====================================
>
>     However, as mentioned by you, once the controls of a given type start responding to a raised event trapped in their respective class (say (B) or (D) above), the sequence within the control group gets governed by the order in which the controls were instantiated. If the situation demands a special order to be observed in code execution, even within similar type controls, and if the overall number of different types of controls is large, tailor-made ancillary mini-collections could perhaps be considered for faster iteration while handling everything within form class itself, without projecting the form class events to control class.
>
> Best wishes,
> A.D. Tejpal
> ------------
>