[AccessD] SINKING EVENTS IN MULTIPLE PLACES

Events are used to tell the object containing another object that the contained object has done 
something.  To put that into English, if a form contains a command button (an object) the command 
button can raise an event called the OnClick (the click event).  The Click event of the command 
button is used to tell the containing object (the form) that the user clicked on the command button.

Remember back in the first lecture I said that while classes are modules, modules are not classes, 
and that only classes could sink or source events.  Our classes can source or “raise” an event.

Before we get into that, you need to understand that like the radio signal that I used as analogy 
for events, more than one containing object can sink an event, in fact when we use classes it is 
quite common for two objects to sink an event.  Oftentimes we will build a wrapper class for a 
control such as a combo, and that class will sink the combo’s events.  However what happens if we 
need to perform processing on the combo’s events that are specific to the form that the combo is in? 
  The answer is to build a normal event sink in the form itself, do form specific processing in that 
event sink, then do generic processing in the wrapper class.  I am going to demonstrate an object 
event being sunk in two places by building an event sink for the first combo in the form I sent you, 
in the form itself.

•	Open frmDemoCtls in design view
•	Paste the following code into the form:

Private Sub Combo11_AfterUpdate()
     Debug.Print Me.Name & ": AfterUpdate"
End Sub

This code simply creates an event sink in the form for combo1 AfterUpdate and prints the form’s name 
and “AfterUpdate” to the debug window when the event fires.

•	Open the form, click into the top combo in the form and type in some characters, then hit enter. 
In the debug window you should see the following:

GotFocus: Text1
LostFocus: Text1
GotFocus: Combo11
BeforeUpdate: Combo11

frmDemoCtls: AfterUpdate

AfterUpdate: Combo11

LostFocus: Combo11
GotFocus: Combo16

Notice that when the combo’s AfterUpdate event fired, the form got control first!  So the control 
was able to perform some processing that it needed to do before our wrapper class got control.  Once 
the form was done and execution stepped out of the event sink on the form, our wrapper class 
clsCtlCbo got control and ran its AfterUpdate event sink code.

This brings up an interesting question though, what happens if the form needs to do some processing 
AFTER our wrapper class processes the event?  It isn’t extremely common but that scenario does occur 
and I have had to handle it on occasion.  I am going to leave that to another lecture because I want 
you to simply absorb the fact that more than one container class can sink an event.

In fact it is quite possible to sink an event in many different classes.  Just to drop an 
interesting idea, it is possible to build a command button on a form, then on another form entirely 
you can sink the click event of the button on the first form!  In other words, click the button on 
FormA and run code in FormB when the button is clicked!  Or run code in BOTH forms when the button 
is clicked.  In fact you could have the button event sunk on as many forms as you wanted.

Now I know that doesn’t sound very useful but this example is just used to get you thinking about 
and understanding that events are broadcast by an object (the button) and sunk by anybody that needs 
to know about the event.  Furthermore the event can be sunk in as many different places as required 
by your program.

In order to sink an event from a command button on form1 over in form2, you have to dimension a 
variable for a command button in form2.  Not that you have a command button variable you must get a 
pointer to the command button on form1, and SET the command button variable in form2 to the command 
button passed in.  Whew, THAT was a mouthful.

In general we have to:

1.	Inside of our class, dimension a pointer to the object we want to sink events for
2.	Get a pointer to the object that we want to sink events for.
3.	Store the pointer in the variable in our class
4.	In our class, build an event sink for the event we want to sink.
5.	Write code in that event sink to do whatever we want done.

Remember that a form module is in fact a class, so we can do all of that stuff right in our form class.

In this lecture we have learned that it is possible to sink events in more than one class.  We have 
added an event sink in our form to sink the AfterUpdate of one of the combos on the form and we 
debug.print to the command window to demonstrate that the event sink in the class is in fact getting 
control.  We also looked in the command window to verify that the form got control first, then our 
combo wrapper class clsCtlCbo got control and its AfterUpdate event sink ran.  Finally we learned 
that an event can be sunk in many different places if needed.

-- 
John W. Colby
www.ColbyConsulting.com