http://kruglinski.blogchina.com/4609030.html

以一个DropTarget为例，我们都知道在MFC里有COleDropTarget实现OLE拖放目标端非常容易,
缺点 MFC 太臃肿近八年没有更新过了, 而且功能类与窗体类分离, 代码不够紧凑, 那么在
ATL/WTL 中要实现 DropTarget 也是非常的容易的, 而且更码更加紧凑完美, 完美的有点变
态,呵呵!

我觉得ATL小组的人曾经一定是些汇编语言狂热者,因为ATL的运行效率真的是太高了,非常高,
难以想象的高.(如果你偏不信可以用WTL向导一个空工程,Release编

译后再用反汇编工具反一下, 看看生成的代码质量如何, 特别是使用 VC6 以后版本的 VC++
编译器编译)

首先向导一个空的不带工具栏和状态栏的 WTL SDI 工程, Viwe type 选择 Edit 这样我们
会得到一个类似 Notepad 界面的程序, 然后分成 6 步完成拖放支持

1.在 stdafx.h 里加上以下语句:
 
#include <atlcom.h>
 
意义是使用 ATL 的 COM 支持类, 包括 CComObject, CComPtr 等
 
2.在WinMain里:
在 ::CoInitialize(NULL) 语句后加入以下语句
::OleInitialize(NULL);
以及在
::CoUninitialize()语句前加入以下语句
::OleUninitialize();
 
意义是在单线程套间中初使化 COM 库, 初使化后便可使用以下功能
a,剪贴板(Clipboard)
b,拖与放(Drag & Drop)
c,对象连接与嵌入(Object linking and embedding,OLE)
d,就地激活(In-place activation)
 
我原来一直以为使用 CoInitialize 就可以了, 可我调用 RegisterDragDrop 总是失败, 并
返回 E_OUTOFMEMORY, 直到我仔细看了函数说明看到下面这句话:
 
Note 
If you use CoInitialize or CoInitializeEx instead of OleInitialize to initialize
COM, RegisterDragDrop will always return an E_OUTOFMEMORY error.
 
很多时候 bug 都是因为不仔细产生的, 呵呵!
 
3. 将 CComObjectRoot 和 IDropTarget 加入 CMainFrame 的派生列表
 
class CMainFrame : public CFrameWindowImpl<CMainFrame>,...,
 public CComObjectRootEx<CComSingleThreadModel>,public IDropTarget
 
4.定义标准DropTarget方法
 
在MainFrm.h的CMainFrm的类定义中定义标准的IDropTarget方法:
 
STDMETHOD(DragEnter)(IDataObject * pDataObject,DWORD grfKeyState,POINTL pt,DWORD * pdwEffect);
STDMETHOD(DragOver)(DWORD grfKeyState,POINTL pt,DWORD * pdwEffect);
STDMETHOD(DragLeave)();
STDMETHOD(Drop)(IDataObject * pDataObject,DWORD grfKeyState,POINTL pt,DWORD * pdwEffect);
 
并在实现文件MainFrm.cpp实现它们.
 
FORMATETC fe={0};
STDMETHODIMP CMainFrame::DragEnter(IDataObject * pDataObject,DWORD grfKeyState,POINTL pt,DWORD * pdwEffect)
{
 CComPtr<IEnumFORMATETC> pEnum;
 pDataObject->EnumFormatEtc(DATADIR_GET,&pEnum);
 while(pEnum->Next(1,&fe,NULL)==NO_ERROR)
 {
  if(fe.cfFormat==CF_TEXT)
  {
   *pdwEffect=DROPEFFECT_COPY;
   break;
  }
 }
 return S_OK;
}
STDMETHODIMP CMainFrame::DragOver(DWORD grfKeyState,POINTL pt,DWORD * pdwEffect)
{
 *pdwEffect=DROPEFFECT_COPY;
 return S_OK;
}
 
STDMETHODIMP CMainFrame::DragLeave()
{
 return S_OK;
}
 
STDMETHODIMP CMainFrame::Drop(IDataObject * pDataObject,DWORD grfKeyState,POINTL pt,DWORD * pdwEffect)
{
 STGMEDIUM stg={0};
 pDataObject->GetData(&fe,&stg);
 LPCTSTR lpData=(LPCTSTR)GlobalLock(stg.hGlobal);
 
 m_view.SetWindowText(lpData);
 
 GlobalUnlock(stg.hGlobal);
 ReleaseStgMedium(&stg);
 
 *pdwEffect=DROPEFFECT_COPY;
 return S_OK;
}
 
 
5.定义 COM 映射表
 
在MainFrm.h的CMainFrm的类定义中加入下面几句:
BEGIN_COM_MAP(CMainFrame)
    COM_INTERFACE_ENTRY(IDropTarget)
END_COM_MAP()
 
6.注册和注销
在WM_CREATE消息的Handler OnCreate中注册
RegisterDragDrop(m_hWnd,this);
在WM_CLOSE消息的Handler OnClose中注销
RevokeDragDrop(m_hWnd);
 
现在差不多已经完成了, 在这里不要问怎么没有见到你写 AddRef, Release, QueryInterface,
ATL 为我们提供了非常高效且多线程安全的实现, 我们要做的只是实现不同的接口, COM 对
象的生存周期管理是基于 "在堆中生成对象" 的假设 (否则还 AddRef, Release干什么).
这里我们的主窗体对象也将在堆中生成.
 
修改一下 Run 函数, 像下面这样来生成主窗体
 
int Run(LPTSTR /*lpstrCmdLine*/ = NULL, int nCmdShow = SW_SHOWDEFAULT)
{
 CMessageLoop theLoop;
 _Module.AddMessageLoop(&theLoop);
 
 //一个COM对象指针
 CComObject<CMainFrame> *pMainFrm=NULL;
 //在堆上分配对象
 CComObject<CMainFrame>::CreateInstance(&pMainFrm);
 
 if(pMainFrm->CreateEx() == NULL)
 {
  ATLTRACE(_T("Main window creation failed!\n"));
  return 0;
 }
 
 //增加引用计数,COM的老规矩,不用我多说
 pMainFrm->AddRef();
 pMainFrm->ShowWindow(nCmdShow);
 
 //开始消息循环,Release编译后都是展开的
 //直接调用GetMessage,TranslateMessage.....
 int nRet = theLoop.Run();
 
 //减少引用计数,COM的老规矩,这里的计数为1,
 //调用Release后对象自动析构
 pMainFrm->Release();
 
 _Module.RemoveMessageLoop();
 return nRet;
}
 
运行一下, 可以从 WinWord 里拖放文本到这个小程序里.
 
从注册时的 RegisterDragDrop(m_hWnd, this) 调用可以看到窗口对象和 COM 对象完美的
融合到了一起, 在 COM 方法中可以很方便的与其它组成部分交互, 比如 Drop 方法中的
m_view.SetWindowText(lpData)调用. 为什么 this 可以自动转成 IDropTarget 指针呢,
因为我们的 CMainFrame 继承了 IDropTarget抽像类, 所以按照面向对象的观念来看
CMainFrame 类 "是一个" IDropTarget 类.
 
其实在 CMainFrame 中只有少数接口继承来的函数会生成函数体, 其它的如消息处理过程
OnCreate, OnClose 等如果代码不是很多,最后都会内联到一个叫做 ProcessWindowMessage
的函数中, 由一个大大的 switch 来处理.
 
再优化一下, 我们如果接口继承的层次太多(其实这个例子里不多), 便会生成庞大虚函数表,
从而影响性能, 这是一些偏执狂对 C++ 一直都指责的地方, 给 CMainFrame 加上
ATL_NO_VTABLE(__declspec(novtable)) 定义, 这样如果是从 CMainFrame 继承, 也只到最
后的实现类才生成虚函数表.
 
使用默认的 Release 编译选项 (最大化速度优先) 编译生成的 exe 只有 36K, 而一个
Win32 Application 向导生成的带窗口空工程编译后都有 40K 了,知道为什么吗? 呵呵, 因
为 ATL 在 Release 编译时用更小更快的启动代码而不是 _WinMainCRTStartup 之类的东东,
并且不使用 CRT, C++ RTTI, C++ 异常处理,以及自定义了一套 malloc, new, free, delete
之类的函数和运算符 (这不就是使用 C++ 语法在写 C 程序嘛! 或者说比 C 更高效, 连 CRT
都不用), 如果再加上
 
/opt:nowin98, /align 之类的指示便会更小.
 
总之, 在我的脑海里: ATL+WTL=快速小巧且界面漂亮的程序,:-)
 
其实这些优化在机器性能猛增的今天已经变的微不足道, 毕竟开发工作不全都是在处理海量
的多媒体数据. 现在用 MFC 的人都少了, 更不用说 ATL 这样出力不讨好的东东, 大家都在
搞 .NET 用 C# 之类的东东, 我一直很不喜欢解释执行的东东, 可往后每台电脑都有了
.NET Framework, 就不存在托管代码和本地代码之分了, 反正发布的软件在哪台电脑里都能
运行, 就像你用 Windows API 来写程序, 系统中已经带好了相关的 DLL, 以后用 .NET 框
架来写程序, 系统中也有 .NET 程序的运行时环境,用户不会管你是真编译的还是解释执行的
或是你少用了几个时钟周期, 发现自己需要转变一下那种偏执狂的想法. 也许什么时候我应
该接受 C# 或是 Java.....