Classic COM中的事件处理连接点和.NET中的委托事件模式

    Connection Points 事件处理机制，正如你所知道的，是其中一个主要的推动力量，用于你的COM 组件和组件使用者之间的双向交流。只是为了唤醒记忆，我将简要地叙述一下Classic COM 组件中的事件处理机制。尤其是支持事件通知的，此COM组件有一个输出接口。 当特殊事件发生时，组件用它来调用客户端。在组件IDL 文件的coclass 这一章中，输出接口标记有[source] 属性。IDL 中的[source]属性允许开发工具和IDEs语法分析类型库，检查对象是否支持一个输出接口 。这些组件的使用者或者客户端通常建立一个接受对象, 此接受 对象,执行这个输出接口。这个接受对象的接口指针由客户端传输到组件。这个组件中断输出接口指针，就像一张包括接受 对象的输出接口指针的机器，而机器中的接受对象乐于从组件中接受通知。无论何时，只要组件需要引起事件，它使用机器来得到接受对象（接受对象预定了通知）的接口指示表。然后，它通过调用输出接口（由接受对象执行）上各自的方法来通知它们。

Classic COM中的连接点

    本质上，COM 对象支持输出接口,执行IConnectionPointContainer 接口。一个想要接受事件通知的客户端为IConnectionPointContainer 接口在COM 对象上面创建QI ，以此来看它是否支持输出接口。如果QI 失败了，对象就不支持事件。如果QI 成功了，客户端通过传输输出接口的IID，调用IConnectionPointContainer 接口上的FindConnectionPoint 方法（也叫EnumConnectionPoints方法）。如果支持此接口，客户端重新接受到与输出接口 相应的IConnectionPoint 接口指针。它然后调用IConnectionPoint::Advise 方法，把它传输到接受对象IUnknown 指针。COM对象为它的机器增添这个IUnknown指针，以此来保持接受对象表，而这些对象表预先定购了通知。客户端从COM对象收到一个cookie，接下来它可以用此cookie来撤销事件通知。当COM对象需要引起事件时，它通过机器来迭代 ，得到所有接受对象的接口指针表，调用输出接口（由接受对象执行）上面相应的事件方法。当客户端不想再接受通知时，通过调用IConnectionPoint::Unadvise方法（而IConnectionPoint::Unadvise方法是靠传递它先前在IConnectionPoint::Advise调用中接受到的cookie而完成的）它从目标机器中移出来。


    简而言之，那就是事件处理机制和Classic COM组件中双向交流的工作过程。大部分关于程序设计的书用了一整章来解释这个结构体系，你可能需要查阅它们来进一步了解这个主题。