I want to expose a .NET class to COM. That's fairly easy:
ComVisible
Guid
to that interfaceNo big deal. This all works.
But, now my question is: I have a few events in that class, that I want to expose to COM as well.
This should be no big deal either, but, when I look at some examples (f.i. code generated by MS' ComInterop tool), I see that the events are declared in a separate interface.
That is: the class that should be ComVisible
, implements 2 interfaces:
ComVisible
ComVisible
.Now, my question is: why is that ? What is the reason for this ?
Why are the ComVisible
events defined in another interface, and why are they just not defined in the interface that contains the methods and properties that should be ComVisible
?
What is the reasoning behind this ?
This is due to the way that COM events work. COM doesn't have any idea what a delegate is, and so its events are implemented using a callback interface. The object which wishes to receive events implements the events interface, passes it to the sender (your code), and the sender calls methods on it. The event interface is thus separate because you don't want someone interested in your events to have to implement the rest of your interface.
Behinds the scenes, event interfaces are managed using "connection points" which allow recipients to connect their callback interfaces to the sender. This implementation requires an assortment of COM interfaces (IConnectionPoint, IConnectionPointContainer, IEnumConnectionPoints, IEnumConnections) and some tedious housekeeping. If you're implementing COM events in e.g. native C++, you have to care about these interfaces. Fortunately as a .NET programmer you don't have to implement them, since .NET will do it for you.