COM Interop: Event Sink Explanation

There are few differences between what I display in my listing and the MSDN listing. One difference is one line in each managed server.

Original Managed server Class attributes: (event source)

<ComSourceInterfaces("EventSource.ButtonEvents, EventSrc")>
[ComSourceInterfaces("EventSource.ButtonEvents, EventSrc")]

Corrected Managed server Class attributes: (event source)


The problem with the original code is that, when the event is sunk, the DispEventAdvise fails with a hex value of 80070002, meaning "File Not Found". You would not be able to see the DispEventAdvise failing, even though you were, actually, instantiating the object properly, if you were developing in Visual Basic. As mentioned in the MSDN article, Raising Events Handled by COM Sink article, the Advise method, and pretty much all connection point details, is hidden in Visual Basic. Anyway, this error seemed ridiculous to me because I was able to instantiate the .NET object and call methods (not illustrated in examples shown in the code listings) without issue. So, I did some research and found this reference on Google Groups where MS MVP, Santhosh Pillai, indicates that the ComSourcesInterfaces class attribute line fails when the type library is created. When I was using the Visual Studio .NET IDE, no such issue is ever displayed. Moreover, the type library is created and, upon visual inspection, appears to be valid.

In any case, changing the one line seemed reasonable since, in C#, there are at least 3 methods to determine the type of an interface (typeof, Type.GetType, and, apparently, the version listed in the original ConCourcesInterface listing) that I am aware of. I found that the suggested change works to perfection and that neither of the other two methods to get the type of the events interface enabled me to successfully sink the event into my (C#) COM client. So, therefore, until Microsoft corrects this (if it is not an intentional disparity between these methods of retrieving the type of an interface), I’ll be using typeof (C#) or GetType (VB).

A second issue that I overcame was that if I didn’t put a DispID attribute on each event listed in the Events interface, the event would not fire properly. In my VB managed server listing I used the attribute as "<DispID(1)>". I have not confirmed that this is necessarily the proper way to do this in VB, but, in any case, you will need to declare the dispatch ID for your event to get it to fire properly.

One last note. In my travels I recall seeing something somewhere that indicated that a person was having difficulty when an underscore was used in the interface name as well. I did not investigate the validity of this, but simply took it to be true and did not use an underscore in my interface names. If you can find the reference elsewhere regarding this please let me know and I’ll update this information.

Hope this helps some of you out there from the ordeal that I had to endure to come to this resolution.

A coworker of mine stumbled across a kb article that seems to indicate the same issue with the event type listed above. Take a read. I haven’t tested any of the resolutions, but found it interesting that the solution I came up with is exactly what is represented in resolution #2. I am surprised that they reference the erroneous information at the start of the article (linking to the Handling Events.. documentation), but yet they don’t correct the code listing. I guess it must be by design *shrug*.

The information on this page is provided "AS IS" with no warranties, and confers no rights.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s