How does EventHandler work? IConnectionPoint!

Article
06/14/2006

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.

Comments

Anonymous
June 14, 2006
Thanks to this code IFeedEvents and IFeedFolderEvents (part of the RSS Platform) now work in VFP. To make the EventHandler method slightly more generic I used...

THIS.oCOMVFP = _vfp.Objects(oSink.Name)

...instead of that FOR loop thru _vfp.Objects.

Also, I added an IID property to the oSink object so oSink.IID could be used in place of the hard coded events IID.

It works really good. This is great stuff (Calvin: this means you!).
Anonymous
June 14, 2006
Hi Craig,
Glad you got it working so quickly!
Yes, using the name as the Objects parameter simplifies the code. Replace the IsNull code with
IF ISNULL(this.oCOMVFP)
this.oCOMVFP=_vfp.Objects(m.osink.Name)
ENDIF
Anonymous
June 16, 2006
Calvin,

Don't get me wrong, I appreciate your constant efforts and support, but I have some suggestions regarding this post of yours.

I think that is almost impossible to understand the essence of what you are doing here unless you are an experienced C++ AND VFP developer.

For instance, I understand more a C++ version for subscribing to events on the RSSFeeds dll, and although I know how COM objects work, I know very little C++.

In your example you addressed one COM element that has source interfaces, thus native foxpro function EVENTHANDLER works already.

Would you consider providing more info on how to "translate" C++ into Foxpro when the COM object does not have a source interface or implements IConnectionPointContainer on other interfaces?

Thank you
Anonymous
June 16, 2006
The comment has been removed
Anonymous
June 19, 2006
Hi Calvin,

I appreciate your prompt reply. Initially, I was able to see the c++ commented out code, but couldn't tell what he rest was.

With your explanation, the code makes more sense to me now than it made before. However I must say that for me to get the desired modification done, without the right knowledge of the technologies involved, would be such a time consuming task that feels discouraging to even start trying. I'd rather find a different way where I understand what I am doing than hacking here and there with unpredictable results.

>>>>What you’re asking for is the answer to the exercise I left for the reader.
Didn't know you had Assembly and x86 machine developers in your audience <bg>

You have basically recreated the VFP EVENTHANDLER function, in other words, we have now 2 options. Wouldn't it make sense if the VFP Team included in the next SP release a change for the native EVENTHANDLER function, addressing the other cases mentioned as well?

I think this is important functionality to just leave it out of the product to the goodwill of a few programmers. But, of course, I may be wrong...

Thanks for the follow up.
Juan
Anonymous
June 20, 2006
The comment has been removed
Anonymous
July 14, 2006
PingBack from http://blog.jlcconsulting.com/PermaLink,guid,22b504fc-bf2e-4d0c-b6e1-e9c25d6ec587.aspx
Anonymous
May 05, 2007
The sample below uses Desktop Window Manager under Windows Vista with Aero to get dynamic live thumbnails
Anonymous
March 02, 2008
PingBack from http://foxpro.ntsl119.com/scr/archives/744
Anonymous
May 29, 2009
PingBack from http://paidsurveyshub.info/story.php?title=calvin-hsia-s-weblog-how-does-eventhandler-work-iconnectionpoint

Partager via

How does EventHandler work? IConnectionPoint!

Comments

Ressources supplémentaires