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.....