How does EventHandler work? IConnectionPoint! - Calvin Hsia's WebLog - Site Home

The EventHandler function allows you to connect some code to an object’s event interface. For example, Word allows you to run code when the user changes the Selected text in a document. An ADODB Recordset will fire events, such as WillMove and MoveComplete when moving from record to record.

The EventHandler function takes 2 objects as parameters: the event source, like Word or a RecordSet, and the event sink, like the code you’d like to run. Your event sink code must Implement an interface defined by the source.

EventHandler then does some handshaking between the two to get the events working.

It queries the Source for IConnectionPointContainer,
then uses that to call EnumConnectionPoints to enumerate the connection points.
The sink object is queried for the interface of each found connection point to see if it’s implemented.
If found, then the IConnectionPoint->Advise method is called to start the event handling.

The sample below creates an ADODB Recordset and makes a few calls to MoveNext, with and without an event sink attached. You can change the event sink connection to be the VFP native EventHandler function, or you can use the generated machine code to show how it works. Both ways return the same results.

Here are a couple issues:

We need a COM interface to the Event Sink (“myclass”) , which is not a COM object. We get that from the _VFP.Objects collection, which is using COM
We need a way to call generated machine code. I used the EnumChildWindows function, which is relatively painless. I just pass it the address of the code to execute as the EnumChildWindowProc, which returns False, so that it’s only called once.
The code has a lot of conditional jumps and some error checking. The jumping needs to be resolved in a 2 pass assembler. That’s what the Jump table does. It records the definitions and references of labels, then after the code is generated, the table is scanned for jump address fixups. Most assemblers use two passes.
The sample code is a little different from the native VFP EventHandler function: it doesn’t enumerate all the connection points, but rather does a FindConnectionPoint for the particular RecordSetEvents interface.

You can modify the sample to bind events in other scenarios. For example, I’ve found some objects may not work properly with EnumConnectionPoints, but work only with FindConnectionPoint. Other people have reported that the object may not have a Source interface, but do implement IConnectionPointContainer on other interfaces.

For example, oleview and navigate to Microsoft Word 11.0 Object library and dbl-click. Navigate to CoClass, CoClass Application

coclass Application {

[default] interface _Application;

[source] dispinterface ApplicationEvents;

[source] dispinterface ApplicationEvents2;

[source] dispinterface ApplicationEvents3;

[default, source] dispinterface ApplicationEvents4;

};

The Word typelibrary shows that the Application interface sources some event interfaces.

If you look at c:\windows\system32\msfeeds.dll (which comes from installing IE7 beta 2) via OleView, there are no Source interfaces. However, you can call the GetWatcher method (the 24^th vTable entry (offset 0x60)) of the IFeedFolder object to get a ConnectionPointContainer object.

As an exercise to the reader (Craig: this means you!), modify the sample code to connect events for RSSFeeds.