用ATL和MFC来创建ActiveX控件

核心提示：连接和事件最后要进行的比较是MFC和ATL各是怎样处理连接点和事件集的，为了管理连接点和事件集，用ATL和MFC来创建ActiveX控件(10)，需要一个COM类来实现IconnectionPointContainer，然后创建一种提供指向IconnectionPoint的指针给客户的方法，而且，好像随着ATL的成熟，

连接和事件

最后要进行的比较是MFC和ATL各是怎样处理连接点和事件集的。为了管理连接点和事件集，需要一个COM类来实现IconnectionPointContainer，然后创建一种提供指向IconnectionPoint的指针给客户的方法。MFC的主控件类，ColeControl，已经有了内置的IconnectionPointContainer，MFC通过连接映射提供了连接点。MFC已经为IPropertyNotifySink定义了连接点和控件的缺省事件集。

为了完善一个基于MFC的控件的缺省事件集，你只要简单的使用ClassWizard’s ActiveX Event tab。在你使用ClassWizard添加事件的时候，Visual Studio更新你的控件的.ODL文件，为潜在的包容器描述外出事件。另外，Visual Studio添加一个函数到你的类中，你可以调用它反过来向包容器激发事件。图9演示了基于MFC的控件的事件触发机制。基于MFC的控件的事件触发函数只是由包容器在它和控件建立连接点时提供的一个Idispatch指针的一些简单的包裹器。

在基于ATL的控件中建立事件则有所不同。在基于ATL的控件中，你从定义控件的.IDL文件中的事件开始。接着你建立了类型库的编译工程文件。图10显示了在IDL中描述的基于ATL的控件的事件集。

一但类型库编译通过，你就可以通过在类视中选择控件的类，在类上右击，然后选择Implement Connection Point，让类视来为你创建一个回调代理了。Visual Studio弹出一个对话框，列出控件类型库中所有可访问的事件接口。你选择那些你希望回调代理做的，Visual Studio就为你写一个代理。图11显示了基于ATL的消息流控制的回调代理。Visual Studio产生的回调代理代表了一个C++友好的函数集，被客户实现的接口所调用。

MFC的IconnectionPointContainer实现是硬分布到ColeControl中，并且每个连接点是由一个连接映射处理的，而ATL的实现是用多重继承处理的。你的控件类继承IconnectionPointContainerImpl和类视生成的代理。如果你开始一个工程的时候，选择了"Supports connection points"，ObjectWizard就为你添加IconnectionPointContainerImpl。如果你忘了标记检查框，你可以写进去。此代码显示了连接点机制是怎样加入一个控件中的。类ATL_NO_VTABLE CATLMsgTrafficCtl ：

{
•••
　 public IConnectionPointContainerImpl<CATLMsgTrafficCtl>,
　 public CProxy_DATLMsgTrafficEvents<CATLMsgTrafficCtl>
•••
　　{
　　LRESULT OnTimer(UINT msg, WPARAM wParam,
　　　　　　　　　　LPARAM lParam,
　　　　　　　　　　BOOL& bHandled) {
　　//•••
　　　　if(nMessagesToShow > m_threshold)
　　　　{
　　　　　　Fire_ExceededThreshold(nMessagesToShow, m_threshold);
　　　　}
　　//•••
　　}
};

作为一个应用框架ATL和MFC的比较

最近，许多开发者开始对使用ATL作为框架来开发应用和控件感兴趣了。当然，MFC已经使用了很长时间了，是一个能够开发可双击的基于Windows的应用的非常成熟的框架。例如，MFC包括了这样的特性作为一个总体文档/视体系结构：Object Linking 和 Embedding支持, 以及工具条和状态栏。

然而，所有这些功能都是有代价的。一些更加普遍的抱怨是MFC的比较深的足迹（无论是在DLL中，或是在静态连接的版本中），以及自身的某种相互依存性。例如，买入MFC的一种特性意味着买入MFC的对象连接和嵌入，这意味着买入MFC的文档/视结构。另一方面，ATL是一个原始的框架，没有任何应用框架goodies。

正象你已经看到的，两个框架都提供创建控件的可行途径。然而，两者都各有千秋，也各有弊病。用MFC编写控件通常更加容易——尤其是如果你不是在开发COM集中的应用并且你需要windowing和drawing支持。ATL的体系架构更加靠近COM的核心，你还会经常发现自己在编写很多的SDK类型的代码——就是说，你在回过头来用window和设备上下文句柄。ATL为更广范围的控件类型提供了很大的支持，象复合控件，基于HTML的控件，没有design-time接口的轻量级的控件等等。MFC仅提供完全成熟的控件。

对ATL进行分支的实现是非常直接的。例如，增加一个接口通常是一件添加接口到继承表，在COM映射中添加一个入口然后实现接口函数的工作。分支MFC的实现通常是一种折磨。例如，添加一个接口到基于MFC的控件意味着处理所有那些接口映射宏。

最后，ATL提供了大量的调试支持，包括接口引用计数以及QueryInterface调试支持，这在MFC中是没有的。

这两种体系架构的区别是非常明显的。通常，MFC使得你很快完成你的工程并更快的运行起来，但是牺牲了灵活性。ATL没有那样快，那样容易使用，但是它是COM友好的。而且，好像随着ATL的成熟，它将会越来越容易使用。