久久婷婷色香五月综合激情,久久综合综合久久综合,三级三级久久三级久久

COM Objects and Interfaces

jay — Tue, 13 Mar 2007 05:57:00 GMT

一个对象实��C��个接口，他的意思就是该对象使用代码实现了接口的每个�Ҏ��

�q�且��些函数通向 com 库提供了 com 的二�q�制指针。然�?/span> com 使这些函数运行在

��h��了一个指向该接口的�Q何客��L��?/font>

Interfaces and Interface Implementations

COM 在接口的定义和实��C��有根本的差别。一个接口实际上是由一�l�定义了用法的相

联系的函数原型组成，只是他不能够被实现。这些函数原型就相当�?/span> C++ 中含有纯虚拟函数的基�c�R��一个接口定义制定了接口的成员函数、调用方法、返回类型、他们的参数的数量和�c�d��Q�这些函数要�q�什么。但是这里�ƈ没有与接口实现相关的东西。一个接口的实现��是�E�序员在一个借口定义上提供的执行相关动作的代码�?/span>

一个接口的实现��是�E�序员在一个借口定义上提供的执行相关动作的代码。客戯��用完全是军_��于接口的定义�?/span>

Interface Pointers and Interfaces

接口实现的一个实例，实际上就是一个指向一�l�方法的指针�Q�即是指指向一个接口的�?/font> 数表�Q�该函数表引用了该接口所有方法的实现�?/font>

每个接口�Q�是一个固定的一�l�方法的集合�Q�在�q�行旉��过 globally unique interface identifier (IID) 来定位。这里， IID �?/span> com 支持�?/span> globally unique identifier (GUID) 的特�D�的实例。这样做��׃��会��生单一�pȝ��上相同名字、接口的多个版本�?/span> COM 之间的冲�H�了�?/span>

一�?span lang="EN-US">COM接口与C++�c�L��不一��L��Q?/span>
一�?span lang="EN-US">COM接口不是一个对象——他只是��单的兌��一�l�函敎ͼ�是客户和�E�序之间通信的二�q�制标准。只要他提供了指向借口�Ҏ��的指针，�q�个对象��可以用��M��语言来实��C��。；
COM接口十强�c�d��的——每个接口有他自��q��借口标识�W�；

· COM接口的不变性——你不能够用老版本的接口标识�W�定义新的版本，接口的IID定义的接口合同是明确的、唯一�?/span> �?/span>

IUnknown and Interface Inheritance

�l�承�?/span> COM 里�ƈ不意味着代码的重用。因为接口没有实现关联，借口�l�承�q�意味着代码�l�承。他的意思仅仅是�Q�一个接口同一个合同关联，��像 C++ 的纯虚拟基类的创建和修改��P��可以��d��Ҏ��或者更�q�一步的加强�Ҏ��的��用。在 COM 里没有选择性��ѝ��如果一个接口由另一个接口��承的话，他就包含了另一个接口定义的所有的�Ҏ��?/span>

Using and Implementing IUnknown

COM 为实现和使用对象和对象的内部通信提供了一个丰富的标准集合。对IUnknown接口的实现和使用的细节，请参见下面主题：QueryInterface: Navigating in an Object 。�?o:p>

Rules for Implementing QueryInterface

��理实现一�?span lang="EN-US">COM对象�?/span> IUnknown::QueryInterface �Ҏ��的三个主要规则：

1�Q�对象必��要有一个标识符�Q?/font>

2�Q�一个对象实例的接口集合必须是静态的�Q?b style="mso-bidi-font-weight: normal">static�Q�；

3�Q�在对象中从��M��一个其他的接口查询此接口都应该成功�?/span>

通过引用计数来管理对象的生命周期

使用 AddRef �Q�） //增加引用
Realase�Q�） //减少引用

jay 2007-03-13 13:57 发表评论

jay — Tue, 13 Mar 2007 02:08:00 GMT

ATL中的对话框类�Q?/strong>
现在我们对ATL中的�H�口�c�L��了一定的了解�Q�接着我们来学习对话框�c�R��在你的��目中，可能有很多对话框资源�Q�从最��单的“关于”模式对话框到复杂的满是控�g的非模式对话框。ATL提供了CSimpleDialog�c�d��CDialogImpl�c�L��化我们��用对话框资源的过�E��?

CSimpleDialog
CSimpleDialog是一个从模版创徏模式对话框的�c�R��它提供了一些标准按�U�（如OK和CANCEL�Q�的处理�q�程。你可以��CSimpleDialog惌��成是一�U�消息对话框�Q�Message Box�Q�，不同的是你可以在对话框编辑器中编辑它的外观�?

要显�C��样一个对话框�Q�比如当你点几Z��帮助”菜单中的“关于”菜单项时显�C�关于对话框�Q�你需要在�ȝ��口类中添加如下的消息映射�Q?
BEGIN_MSG_MAP( CMyMainWindow ) COMMAND_ID_HANDLER( ID_HELP_ABOUT, onHelpAbout ) ... LRESULT onHelpAbout( WORD, WORD, HWND, BOOL& ) { CSimpleDialog dlg; int ret = dlg.DoModal(); return 0; }
我们可以看到对话框资源的ID�Q�IDD_DIALOG1�Q�被作�ؓ一个模版参��C��递给CSimpleDialog�c�，DoModal�Ҏ��昄��对话框。当用户点击OK按钮�Ӟ��CSimpleDialog�c�d��闭对话框�q�返回按钮的ID。（CSimpleDialog�c�d��C��Ҏ��钮IDOK�Q�IDCANCEL�Q�IDABORT�Q�IDRETRY�Q�IDIGNORE�Q�IDYES和IDNO的响应。）

CDialogImpl
CSimpleDialog�c�d��能够处理��单的模式对话框，对于更加复杂的对话框或者模式对话框�Q�就要用到CDialogImpl�c�R��（其实CSimpleDialog是CDialogImpl中的一�U�特例。）

如果我们需要实��C��个非模式对话框，我们必须从CDialogImpl�z��Z��个新�c�，�q�将新类的类名作为模板参��C��递给CDialogImpl�c�，��p��前面的CWindowImpl一��P��
class CMyModelessDialog: public CDialogImpl {
和CSimpleDialog不同�Q�我们不需要将对话框资源的ID作�ؓ模板参数传递给它，但是我们必须��这个类和对话框资源联系��h��Q�我们通过在类中定义一个枚丑֏�量实玎ͼ�
public: enum { IDD = IDD_DIALOG1 };
然后定义消息映射表：
BEGIN_MSG_MAP( CMyDialog ) MESSAGE_HANDLER( WM_INITDIALOG, OnInitDialog ) MESSAGE_HANDLER( WM_CLOSE, OnClose ) ... END_MSG_MAP()
响应函数的定义和前面的一��P��但是有一炚w��要注意，如果你实现的是一个非模式对话框，那么在WM_CLOSE消息的响应函��C��必须调用DestroyWindow�Q?pre>LRESULT OnClose( UINT, WPARAM, LPARAM, BOOL& ) { DestroyWindow(); return 0; } ... }; // CMyModelessDialog 要在屏幕上创��样一个对话框�Q�需要创��个类的一个实例�ƈ调用Create�Ҏ��Q?
CMyModelessDialog dlg; dlg.Create( wndParent );
如果对话框资源没有选中WS_VISIBLE属性，我们需要这栯��对话框显�C�出来：
dlg.ShowWindow( SW_SHOW );
下面的例子有一个非模式的对话框可以接受用户输入的字�W�串�Q�然后在�ȝ��口中昄��q�个字符丌Ӏ�对话框中有一个编辑框控�g和一个按钮；当按钮被点击�Ӟ��对话框调用它所属窗口的DoSomething�Ҏ��对编辑框中的字符串进行处理，它所属的�H�口是一个超�c�d��的列表框控�g�Q�DoSomething�Ҏ��的功能是��字�W�串��d��到列表框中�?
#include "atlbase.h" CComModule _Module; #include "atlwin.h" #include "resource.h" class CMyWindow: public CWindowImpl { public: DECLARE_WND_SUPERCLASS( "MyWindow", "listbox" ) BEGIN_MSG_MAP( CMyWindow ) MESSAGE_HANDLER( WM_DESTROY, OnDestroy ) END_MSG_MAP() LRESULT OnDestroy( UINT, WPARAM, LPARAM, BOOL& ) { PostQuitMessage( 0 ); return 0; } void DoSomething( LPCTSTR s ) { SendMessage( LB_ADDSTRING, 0, reinterpret_cast(s) ); } }; class CMyDialog: public CDialogImpl { public: enum { IDD = IDD_DIALOG1 }; BEGIN_MSG_MAP( CMyDialog ) COMMAND_ID_HANDLER( IDC_BUTTON1, OnButton ) MESSAGE_HANDLER( WM_INITDIALOG, OnInitDialog ) MESSAGE_HANDLER( WM_CLOSE, OnClose ) END_MSG_MAP() LRESULT OnButton(WORD, WORD, HWND, BOOL&) { char buf[100]; m_ed.GetWindowText( buf, 100 ); m_owner.DoSomething( buf ); return 0; } LRESULT OnInitDialog( UINT, WPARAM, LPARAM, BOOL& ) { m_owner.Attach( GetParent() ); CenterWindow( m_owner ); m_ed = GetDlgItem( IDC_EDIT1 ); return TRUE; } LRESULT OnClose( UINT, WPARAM, LPARAM, BOOL& ) { DestroyWindow(); m_owner.Detach(); return 0; } CMyWindow m_owner; CWindow m_ed; }; CMyDialog dlg; int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { _Module.Init( NULL, hInstance ); CMyWindow win; win.Create( NULL, CWindow::rcDefault, _T("modeless dialog test"), WS_OVERLAPPEDWINDOW|WS_VISIBLE ); dlg.Create( win ); dlg.ShowWindow( SW_SHOW ); MSG msg; while( GetMessage( &msg, NULL, 0, 0 ) ){ if( !IsWindow(dlg) || !dlg.IsDialogMessage( &msg ) ){ DispatchMessage( &msg ); } } _Module.Term(); return 0; }
指定�H�口�cȝ��信息�Q?/strong>
�q�篇文章的大部分内容都是在讲�q�怎样处理�H�口�cȝ��行�ؓ——窗口怎样响应消息。在行�ؓ之外�Q�一个窗口类�q�具有一些其它的重要的属性，比如样式、类名、背景颜色和指针�{�等。这一节介�l�怎样使用ATL中提供的宏来指定�q�些属性�?

使用Window Traits指定�H�口的样�?
到目前�ؓ止，所有例子中的窗口样式都是在调用Create�Ҏ��时指定的�Q?
CMyWindow wnd; wnd.Create( NULL, CWindow::rcDefault, _T("Hello"), WS_OVERLAPPEDWINDOW|WS_VISIBLE );
如果你不指定��M��样式和扩展样式，ATL��用默认的样式�Q�这些默认的样式是作为窗口的特征定义的，默认特征是CControlWinTraits�Q�定义如下：
typedef CWinTraits CControlWinTraits;
CWinTraits是一个模板类�Q�它需�?个参敎ͼ��H�口样式、扩展窗口样式�?

在CWindowImpl的定义中�Q�CControlWinTraits作�ؓ默认的模板参��C��递给CWindowImpl�Q?
template class CWindowImpl : public ...
所以在默认情况下，从CWindowImpl�z��的窗口都��h��可视、子�H�口、裁剪兄弟窗口、裁减子�H�口的属性�?

我们也能定义自己的窗口特征：
typedef CWinTraits MyTraits;
然后�Q�从CWindowImpl�z��一个窗口类�Q�指定自��q��H�口特征�Q?
class CMyWindow: public CWindowImpl {...};
或者象下面�q�样更加直接�Q?
class CMyWindow: public CWindowImpl< CMyWindow, CWindow, CWinTraits > {...};
注意�Q�我们必��L��供全部的三个模板参数�Q�派生类�Q�基�c�（CWindow�Q�和特征�c�R�?

CMyWindow�H�口现在��h��的默认的样式为“可见的弹出�H�口”，所以我们可以在Create�Ҏ��中省略样式参敎ͼ�
CMyWindow wnd; wnd.Create( NULL, CWindow::rcDefault, _T("Hello") ); // style: WS_OVERLAPPEDWINDOW|WS_VISIBLE
我们也可以重写窗口特征：
ovwnd.Create( NULL, CWindow::rcDefault, _T("Hello"), WS_OVERLAPPEDWINDOW ); // not visible
�H�口特征也可以包含扩展样式：
class CClientWindow: public CWindowImpl > {...};
DECLARE_WND_CLASS
使用DECLARE_WND_CLASS宏可以指定窗口的�c�d��Q?
DECLARE_WND_CLASS("my window class");
�q�等价于�Q?pre>DECLARE_WND_CLASS_EX( "my window class", CS_HREDRAW|CS_VREDRAW|CS_DBLCLKS, // default style COLOR_WINDOW // default color ); DECLARE_WND_CLASS_EX
使用DECLARE_WND_CLASS_EX宏可以指定窗口类名、样式和背景颜色�Q?
class CMyWindow: public CWindowImpl { public: DECLARE_WND_CLASS_EX( "my window class", // class name CS_HREDRAW|CS_VREDRAW, // class style COLOR_WINDOW // background color ); BEGIN_MSG_MAP(CMyWindow) ...
所谓的�H�口�c�d��是指注册的窗口类的名字，如果我们不指定窗口类名，ATL��自动生成一个，但是当我们��用Spy++之类的工��L��时候，你将会发现我们自己取的类名比"ATL:00424bd0"之类的名字要有用得多�?

�c�L��式是按照按位或组合的�?

背景颜色必须是标准系�l�颜色之一�?

CWndClassInfo
我们也可以定义超出DECLARE_WND_宏能力之外的�H�口�c�R��如果你看看DECLARE_WND_CLASS的定义你��׃��发现它定义了一个CWndClassInfo�l�构�Q��ƈ且一个函数返回这�U�结构类型的��|��
#define DECLARE_WND_CLASS(WndClassName) \ static CWndClassInfo& GetWndClassInfo() \ { \ static CWndClassInfo wc = \ { \ { sizeof(WNDCLASSEX), CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS, \ StartWindowProc, \ 0, 0, NULL, NULL, NULL, (HBRUSH)(COLOR_WINDOW + 1), NULL, \ WndClassName, NULL }, \ NULL, NULL, IDC_ARROW, TRUE, 0, _T("") \ }; \ return wc; \ }
CWndClassInfo�l�构提供了更灉|��的自定义的可能，它是�q�样定义的：
struct CWndClassInfo { struct WNDCLASSEX { UINT cbSize; UINT style; WNDPROC lpfnWndProc; int cbClsExtra; int cbWndExtra; HINSTANCE hInstance; HICON hIcon; HCURSOR hCursor; HBRUSH hbrBackground; LPCSTR lpszMenuName; LPCSTR lpszClassName; HICON hIconSm; } m_wc; LPCSTR m_lpszOrigName; WNDPROC pWndProc; LPCSTR m_lpszCursorID; BOOL m_bSystemCursor; ATOM m_atom; CHAR m_szAutoName[13]; ATOM Register(WNDPROC* p); };
例如�Q�要指定一个窗口的指针�Q�我们可以将m_lpszCursorID讄��为指针的名字�Q�如果它是一个系�l�指针，��m_bSystemCursor讄��为TRUE�Q�否则设�|��ؓFALSE。注意DECLARE_WND_CLASS宏是怎样��这两个成员变量分别讄��为IDC_ARROW �?TRUE的。既然DECLARE_WND_宏不能让我们改写�q�些默认的��|��我们可以�q�样做：
class CMyWindow: public CWindowImpl { public: static CWndClassInfo& GetWndClassInfo() { // a manual DECLARE_WND_CLASS macro expansion // modified to specify an application-defined cursor: static CWndClassInfo wc = { { sizeof(WNDCLASSEX), CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS, StartWindowProc, 0, 0, NULL, NULL, NULL, (HBRUSH)(COLOR_WINDOW + 1), NULL, "MyWindow", NULL }, NULL, NULL, MAKEINTRESOURCE(IDC_CURSOR1), FALSE, 0, _T("") }; return wc; } ...
�l�论�Q?/strong>
ATL提供了一�U�简单的、雅致的�q�且功能强大的窗口编�E�模式。在那些方便的封装好了的函数、消息映��和宏之外，�q�有一些技术诸如链接、窗口的子类化和��类化、被包含的窗口和消息反射�{�也使得设计和实现窗口和对话框非常灵�z�R��或许ATL�l��h最��q��印象��是�Q�功能强大、灵�z�L��好�Q�但是不会占用太多的内存和系�l�开销�?img src ="http://m.shnenglu.com/yishanhante/aggbug/19690.html" width = "1" height = "1" />

jay 2007-03-13 10:08 发表评论

jay — Tue, 13 Mar 2007 02:07:00 GMT

被包含的�H�口�Q?/strong>
一个被包含的窗口是一个不响应��M��消息的窗口，它将收到的所有消息重新发送到另外一个窗口的消息映射�Q�这个另外的�H�口��是它的容器�H�口。通常情况下，被包含的�H�口是它的容器窗口的子窗口，但情况�ƈ不是��L��q�样。容器窗口�ƈ不是必须�{�同于父�H�口�Q�包含与被包含的关系取决于C++�c�，被包含的�H�口是容器窗口类的一个数据成员，而父�H�口和子�H�口的关�p�M��现在屏幕上，它们的关�p�L��创徏�H�口时确定的�?

一个被包含的窗口徏立在已注册的�H�口�cȝ��基础之上�Q�比如编辑框控�g。如果一个编辑框被包含，那么发送到它的消息实际上被它的容器�H�口的消息映��处理。��用这�U�方法，可以改变�~�辑框控件的标准行�ؓ。这有点�c�M��于子�c�d��但是不需要定义新�c�L��子类化控件。和前面那个定义CnoNumEdit�c�d��应WM_CHAR消息的例子相比，处理WM_CHAR消息的容器窗口类看�v来如下：
class CMyWindow: public CWindowImpl { CContainedWindow m_contained; public: CMyWindow(): m_contained( _T("edit"), this, 99 ) { } ...
CmyWindow是一个容器窗口类�Q�它的构造函数对CcontainedWindow�c�d��的成员做�q�样的初始化�Q�被包含的窗口是�~�辑框，发送它的消息到“this”（它的父窗口）�Q��用可选消息映��表99�?pre>BEGIN_MSG_MAP( CMyWindow ) MESSAGE_HANDLER( WM_CREATE, OnCreate ) MESSAGE_HANDLER( WM_DESTROY, OnDestroy ) ALT_MSG_MAP( 99 ) // contained window''s messages come here... MESSAGE_HANDLER( WM_CHAR, OnChar ) END_MSG_MAP() 当父�H�口被创建的时候，被包含的�H�口也被创徏�Q�在WM_CREATE消息的响应函��C��Q�。因��包含的控件是以编辑框为基��的，所以它在屏�q�上看�v来象一个编辑框�Q?
LRESULT OnCreate( UINT, WPARAM, LPARAM, BOOL& ) { RECT rc = { 10, 10, 200, 35 }; m_contained.Create( *this, rc, _T("non-numeric edit"), WS_CHILD|WS_VISIBLE|WS_BORDER, 0, 666 ); return 0; }
在这个例子中�Q�容器窗口同时也是被包含�H�口的父�H�口�?

当被包含的窗口收到WM_CHAR消息�Ӟ��容器�H�口的OnChar成员函数被调用。这个函数和前面的CnoNumEdit例子中的相同�Q�但是在�q�个例子中，它时容器�cȝ��成员函数�?
LRESULT OnChar( UINT, WPARAM wParam, LPARAM, BOOL& bHandled ) { TCHAR ch = wParam; if( _T(''0'') <= ch && ch <= _T(''9'') ) MessageBeep( 0 ); else bHandled = FALSE; return 0; } LRESULT OnDestroy( UINT, WPARAM, LPARAM, BOOL& ) { PostQuitMessage( 0 ); return 0; } };
我们同样也可以用被包含的�H�口来子�c�d��对话框中已经存在的控�Ӟ��和正规的子类化不同，被子�c�d��的窗口的消息时被容器�H�口捕获的。在下面的例子中�Q�一个对话框子类化了一个编辑框控�g�Q�把它�{化成了被包含的窗口；那个对话框（容器�Q�捕获WM_CHAR消息�q�忽略掉数字字符�Q�然后在发送到�~�辑框控件。（CdialogImpl在ATL中的对话框类一节讲�q�。）
class CMyDialog: public CDialogImpl { public: enum { IDD = IDD_DIALOG1 }; // contained window is an edit control: CMyDialog(): m_contained( "edit", this, 123 ) { } BEGIN_MSG_MAP( CMyDialog ) MESSAGE_HANDLER( WM_INITDIALOG, OnInitDialog ) ALT_MSG_MAP( 123 ) // contained window''s messages come here... MESSAGE_HANDLER( WM_CHAR, OnChar ) END_MSG_MAP() LRESULT OnInitDialog( UINT, WPARAM, LPARAM, BOOL& bHandled ) { // when the dialog box is created, subclass its edit control: m_contained.SubclassWindow( GetDlgItem(IDC_EDIT1) ); bHandled = FALSE; return 0; } LRESULT OnChar( UINT, WPARAM wParam, LPARAM, BOOL& bHandled ) { TCHAR ch = wParam; if( _T(''0'') <= ch && ch <= _T(''9'') ) MessageBeep( 0 ); else bHandled = FALSE; return 0; } CContainedWindow m_contained; };
消息反射�Q?/strong>
前面讲述了一些扩展窗口功能的�Ҏ��Q�这些方法是通过使窗口响应发往�H�口的消息实现的。和前面的方法相反，消息反射是�ɽH�口能够响应从它们自己发出的消息�?

当用户和控�g交互的时候，控�g通常使发送一个WM_COMMAND或者WM_NOTIFY消息�l�它的父�H�口�Q�然后父�H�口做出响应�Q�比如：
class CParentWindow: CWindowImpl { // 假设�q�个�H�口有一个按钮型的子�H�口�Q? // �q�且�?ID �?ID_BUTTON BEGIN_MSG_MAP( CParentWindow ) COMMAND_ID_HANDLER( ID_BUTTON, OnButton ) MESSAGE_HANDLER( WM_CTLCOLORBUTTON, OnColorButton ) ...
当按钮被按下的时候，它发送一个命令消息给父窗口，然后CParentWindow::OnButton被调用。同理，当按钮需要被�l�制的时候，它发送WM_CTLCOLORBUTTON消息�l�父�H�口�Q�CParentWindow::OnColorButton响应�q�个消息�Q�它使用特定的画��L��制控件�?

某些情况下，让控件自己响应它发送出�ȝ��消息比让父窗口响应要好得多。ATL提供了消息反��的机制�Q�当控�g向父�H�口发送消息的时候，父窗口能够将消息反射�l�控件�?
class CParentWindow: CWindowImpl { BEGIN_MSG_MAP( CParentWindow ) MESSAGE_HANDLER( WM_CREATE, OnCreate ) MESSAGE_HANDLER( WM_DESTROY, OnDestroy ) ...other messages that CParentWindow will handle... REFLECT_NOTIFICATIONS() END_MSG_MAP() ...
当父�H�口收到一个消息，先查扑֮�的消息映��表�Q�如果没有和�q�个消息相匹配的入口�Q�则REFLECT_NOTIFICATIONS宏��得该消息被反��给发送这个消息的控�g。控件可以提供响应反��消息的处理函数�Q�如下：
class CHandlesItsOwnMessages: CWindowImpl { public: DECLARE_WND_SUPERCLASS( _T("Superbutton"), _T("button") ) BEGIN_MSG_MAP( CHandlesItsOwnMessage ) MESSAGE_HANDLER( OCM_COMMAND, OnCommand ) MESSAGE_HANDLER( OCM_CTLCOLORBUTTON, OnColorButton ) DEFAULT_REFLECTION_HANDLER() END_MSG_MAP() ...
注意�Q�反��消息的消息标志以OCM_开��_��而不是WM_。这可以让你区分�q�个消息�I�竟是否是被反射回来的�?

�q�个控�g要么是这个类的实例，要么是一个被子类化的按钮控�g。例如：
// in CParentWindow: CHandlesItsOwnMessages m_button; LRESULT OnCreate( UINT, WPARAM, LPARAM, BOOL& ) { RECT rc; // initialize appropriately m_button.Create( *this, rc, _T("click me"), WS_CHILD|WS_VISIBLE ); ...
或者，如果�q�个按钮控�g是已存在的（例如�Q�父�H�口是一个对话框�Q�：
m_button.SubclassWindow( GetDlgItem(ID_BUTTON) );
下面的例子定义了一个CstaticLink�c�，它是一个Static控�g�Q�当点击它的时候，��打开一个指定的�|�页。所有从CstaticLink发送出�ȝ��消息都被它的父窗口反��回来（在这个例子中�Q�用到对话框�Q�请看ATL中的对话框类�q�一节）。除了响应反��回的命令消息，CstaticLink�q�处理反��回的WM_CTLCOLORSTATIC消息以便它能够让自己在点��d��和点��d��昄��不同的颜艌Ӏ?
#include "stdafx.h" #include "resource.h" CComModule _Module; class CStaticLink : public CWindowImpl { /* Based on CStaticLink by Paul DiLascia, C++ Q&A, Microsoft Systems Journal 12/1997. Turns static controls into clickable "links" -- when the control is clicked, the file/program/webpage named in the control''s text (or set by SetLinkText()) is opened via ShellExecute(). Static control can be either text or graphic (bitmap, icon, etc.). */ public: DECLARE_WND_SUPERCLASS( _T("StaticLink"), _T("Static") ) CStaticLink() : m_colorUnvisited( RGB(0,0,255) ), m_colorVisited( RGB(128,0,128) ), m_bVisited( FALSE ), m_hFont( NULL ) { } void SetLinkText( LPCTSTR szLink ) { USES_CONVERSION; m_bstrLink = T2OLE( szLink ); } BEGIN_MSG_MAP(CStaticLink) // uses message reflection: WM_* comes back as OCM_* MESSAGE_HANDLER( OCM_COMMAND, OnCommand ) MESSAGE_HANDLER( OCM_CTLCOLORSTATIC, OnCtlColor ) MESSAGE_HANDLER( WM_DESTROY, OnDestroy ) // not a reflected message DEFAULT_REFLECTION_HANDLER() END_MSG_MAP() LRESULT OnDestroy( UINT, WPARAM, LPARAM, BOOL& ) { if( m_hFont ) DeleteObject( m_hFont ); return 0; } LRESULT OnCommand( UINT, WPARAM wParam, LPARAM, BOOL& ) { USES_CONVERSION; int code = HIWORD( wParam ); if( code == STN_CLICKED || code == STN_DBLCLK ){ if( m_bstrLink.Length() == 0 ){ GetWindowText( &m_bstrLink ); } if( (int)ShellExecute( *this, _T("open"), OLE2T(m_bstrLink), NULL, NULL, SW_SHOWNORMAL ) > 32 ){ m_bVisited = TRUE; // return codes > 32 => success Invalidate(); }else{ MessageBeep( 0 ); ATLTRACE( _T("Error: CStaticLink couldn''t open file") ); } } return 0; } LRESULT OnCtlColor( UINT, WPARAM wParam, LPARAM, BOOL& ) { // notify bit must be set to get STN_* notifications ModifyStyle( 0, SS_NOTIFY ); HBRUSH hBr = NULL; if( (GetStyle() & 0xff) <= SS_RIGHT ){ // it''s a text control: set up font and colors if( !m_hFont ){ LOGFONT lf; GetObject( GetFont(), sizeof(lf), &lf ); lf.lfUnderline = TRUE; m_hFont = CreateFontIndirect( &lf ); } HDC hDC = (HDC)wParam; SelectObject( hDC, m_hFont ); SetTextColor( hDC, m_bVisited ? m_colorVisited : m_colorUnvisited ); SetBkMode( hDC, TRANSPARENT ); hBr = (HBRUSH)GetStockObject( HOLLOW_BRUSH ); } return (LRESULT)hBr; } private: COLORREF m_colorUnvisited; COLORREF m_colorVisited; BOOL m_bVisited; HFONT m_hFont; CComBSTR m_bstrLink; }; // CStaticLink class CReflectDlg : public CDialogImpl { public: enum { IDD = IDD_DIALOG1 }; BEGIN_MSG_MAP(CReflectDlg) COMMAND_RANGE_HANDLER( IDOK, IDCANCEL, OnClose ) MESSAGE_HANDLER(WM_INITDIALOG, OnInitDialog) REFLECT_NOTIFICATIONS() // reflect messages back to static links END_MSG_MAP() LRESULT OnInitDialog(UINT, WPARAM, LPARAM, BOOL&) { CenterWindow( GetParent() ); // a textual static control: s1.SubclassWindow( GetDlgItem(IDS_TEST1) ); // a static control displaying an icon s2.SubclassWindow( GetDlgItem(IDS_TEST2) ); // set the icon''s link s2.SetLinkText( _T("http://www.microsoft.com") ); return 1; } LRESULT OnClose(UINT, WPARAM wID, HWND, BOOL& ) { ::EndDialog( m_hWnd, wID ); return 0; } private: CStaticLink s1, s2; }; // CReflectDlg int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR, int nCmdShow) { _Module.Init( NULL, hInstance ); CReflectDlg dlg; dlg.DoModal(); _Module.Term(); return 0; }

jay 2007-03-13 10:07 发表评论

jay — Tue, 13 Mar 2007 01:52:00 GMT

摘要�Q�讨论Active Template Library (ATL) 3.0中的一些类�Q�这些类围绕着Windows API建立了一个面向对象的�~�程框架�Q��用这个框�Ӟ��可以��化Microsoft® Windows®�~�程�q�且只需要很��的�pȝ��开销。内容包括：考察对窗口做了简单封装的CWindow�c�；使用CWindowImpl�q�行消息处理和消息映��；使用ATL中的对话框类以及扩展现有�H�口�cȝ��功能的方法�?

��介：
虽然Active Template Library (ATL)主要是�ؓ了支持COM开发而设计的�Q�但它确实包含了很多可用于窗口设计的�c�R��这些窗口类和ATL中的其它�c�M��P��都是��Z��模版的，�q�且只需要花费很��系�l�开销。这��文章就向我们演�C�Z��使用ATL创徏�H�口和对话框�q�进行消息处理的基本�Ҏ��?
�q�篇文章假设读者熟悉C++语言和Windows�E�序设计�Q�但是�ƈ不一定要求读者具有COM斚w��的知识�?

CWindow:
在ATL�H�口�c�M��Q�CWindow是最基本的。这个类对Windows API�q�行了面向对象的包装�Q�它��装了一个窗口句柄，�q�提供一些成员函数来操作它，�q�些函数包装了相应的Windows API�?

标准的Windows�E�序设计看�v来象�q�样�Q?
HWND hWnd = ::CreateWindow( "button", "Click me", WS_CHILD, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, hInstance, NULL ); ::ShowWindow( hWnd, nCmdShow ); ::UpdateWindow( hWnd );
使用ATL中的CWindow�c�d��Q�等效代码如下：
CWindow win; win.Create( "button", NULL, CWindow::rcDefault, "Click me", WS_CHILD ); win.ShowWindow( nCmdShow ); win.UpdateWindow();
我们应该在我们的大脑中我们应该保持这样一个概念：ATL的窗口对象与Windows�pȝ��中的�H�口是不同的。Windows�pȝ��中的�H�口指的是操作系�l�中�l�持的一块数据，操作�pȝ��靠这块数据来操作屏幕上的一块区域。而一个ATL�H�口对象�Q�是CWindow�cȝ��一个实例，它是一个C++对象�Q�它的内部没有保存�Q何有兛_��q�区域或者窗口数据结构的内容�Q�只保存了一个窗口的句柄�Q�这个句柄保存在它的数据成员m_hWnd中，CWindow对象和它在屏�q�上昄��出来的窗口就是靠�q�个句柄联系��h��的�?br />理解了ATL中的�H�口对象和Windows�pȝ��中窗口的区别�Q�就更加�Ҏ��理解CWindow对象的构造与�H�口的创建是两个分开的过�E�。我们再看看前面的代码，��׃��发现�Q�首先是一个CWindow对象被构造：
CWindow win;
然后创徏它的�H�口�Q?pre>win.Create( "button", NULL, CWindow::rcDefault, "Click me", WS_CHILD ); 我们也可以构造一个CWindow对象�Q�然后把它和一个已�l�存在的�H�口兌��h��Q�这��h��们就可以通过CWindow�cȝ��成员函数来操作这个已�l�存在的�H�口。这�U�方法非常有用，因�ؓCWindow�c�L��供的函数都是��装好了的，用�v来很方便�Q�比如CWindow�c�M��的CenterWindow, GetDescendantWindow�{�函数用��h��比直接使用Windows API方便得多�?
HWND hWnd = CreateWindow( szWndClass, "Main window", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, hInstance, NULL ); // 下面的方法中可以任选一�U�： // CWindow win( hWnd ); // 通过构造函数关�? // �? // CWindow win; // win = hWnd; // 通过赋值操作符兌�� // �? // CWindow win; // win.Attach( hWnd ); // 使用Attach()�Ҏ��兌�� win.CenterWindow(); // 现在可以使用win对象来代替hWnd�q�行操作 win.ShowWindow( nCmdShow ); win.UpdateWindow();
CWindow�c�M��提供了一个HWND操作�W�，可以把CWindow�cȝ��对象转化为窗口句柄，�q�样�Q��Q何要求��用HWND的地斚w��可以使用CWindow�cȝ��对象代替�Q?
::ShowWindow( win, nCmdShow ); // 此API函数本来要求HWND�c�d��的参�?/pre>CWindow�c�M��得对�H�口的操作更��单，而且不会增加�pȝ��开销——它�l�过�~�译和优化后的代码与使用�U�API�~�程的代码是�{��h的�?br />
不幸的是�Q�CWindow�c�M��能让我们自己军_��H�口如何响应消息。当�Ӟ��我们可以使用CWindow�c�L��供的�Ҏ��来��一个窗口居中或隐藏�Q�甚臛_��以向一个窗口发送消息，但是当窗口收到消息后怎么处理则取决于创徏�q�个�H�口时��用的�H�口�c�，如果我们是创建的是”button”类的窗口，那么它的表现��p��个按钮，如果用”listbox”类创徏�Q�那它就��h��跟列表框相同的行为，使用CWindow�c�L��们没有办法改变这炏V��幸好，ATL为我们提供了另外一个类CWindowImpl�Q�它允许我们指定�H�口的新行�ؓ�?

CWindowImpl:
CWindowImpl�c�L��从CWindow�c�L��生的�Q�所以我们依然可以��用CWindow�c�M��的成员函敎ͼ�但是CWindowImpl�cȝ��功能更强大，它允许我们指定窗口怎样处理消息。在传统的窗口编�E�中�Q�如果我们要处理�H�口消息�Q�我们必��M��用窗口函敎ͼ�但是使用ATL�Q�我们只需要在我们的ATL�H�口�c�M��定义一个消息映��?

首先�Q�从CWindowImpl�c�L��生自��q��H�口�c�，如下�Q?
class CMyWindow : public CWindowImpl {
注意�Q�我们自��q��c�d��必须作�ؓ一个模版参��C��递给CWindowImpl�c�R�?

然后在类的定义里面定义如下的消息映射�Q?
BEGIN_MSG_MAP(CMyWindow) MESSAGE_HANDLER(WM_PAINT,OnPaint) MESSAGE_HANDLER(WM_CREATE,OnCreate) MESSAGE_HANDLER(WM_DESTROY,OnDestroy) END_MSG_MAP()
下面�q�句
MESSAGE_HANDLER(WM_PAINT,OnPaint)
的意思是�Q�当WM_PAINT消息到达�Ӟ��调用CMyWindow::OnPaint成员函数�?

最后就是定义处理消息的函数了，如下�Q?
LRESULT OnPaint( UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled ) { ... } LRESULT OnCreate( UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled ) { ... } LRESULT OnDestroy( UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled ) { ... } }; // CmyWindow
�q�些函数中的参数意义为：�W�一个是消息ID�Q�中间的两个参数的意义取决于消息�c�d��Q�第四个参数是一个标志，用它来决定这个消息是已经处理完了�q�是需要进一步的处理。关于这些参敎ͼ�我们在Message Map��结有更详细的讨论�?

当窗口收��C��个消息，它将从消息映��表的顶部开始查扑֌�配的消息处理函数�Q�因此把最常用的消息放在消息映��表的前面是个不错的注意。如果没有找到匹配的消息处理函数�Q�则�q�个消息被发送到默认的窗口过�E�进行处理�?

ATL的消息映��表��装了Windows的消息处理过�E�，它比传统的窗口函��C��的大量switch分支或者if语句看�v来更加直观�?

要创��Z��个基于CWindowImpl�z��cȝ��H�口�Q�请调用CWindowImpl�cȝ��Create�Ҏ��Q?
CMyWindow wnd; // 构造一�?CMyWindow �cȝ��对象 wnd.Create( NULL, CWindow::rcDefault, _T("Hello"), WS_OVERLAPPEDWINDOW|WS_VISIBLE );
注意�Q�CWindowImpl�cȝ��Create�Ҏ��与CWindow�cȝ��Create�Ҏ��略有不同�Q�在CWindow�cȝ��Create中，我们必须指定一个注册了的窗口类�Q�但是CWindowImpl则不同，它创��Z��个新的窗口类�Q�因此，不需要�ؓ它指定窗口类�?

一个简单而完整的�C�Z��Q?br />
�q�篇文章中的大部分示例都只是代码片段�Q�但是下面列出的是一个完整的Hello world的示例程序。虽然我们��用的是ATL�Q�但是没有涉及到COM�Q�因此在使用Visual C++®建立��目的时候，我们选择Win32® application而不是ATL COM�Q?
在stdafx.h文�g中，加入下面几行�Q?
#include extern CComModule _Module; #include
在hello.cpp文�g中，写如下代码：
#include "stdafx.h" CComModule _Module; class CMyWindow : public CWindowImpl { BEGIN_MSG_MAP( CMyWindow ) MESSAGE_HANDLER( WM_PAINT, OnPaint ) MESSAGE_HANDLER( WM_DESTROY, OnDestroy ) END_MSG_MAP() LRESULT OnPaint( UINT, WPARAM, LPARAM, BOOL& ){ PAINTSTRUCT ps; HDC hDC = GetDC(); BeginPaint( &ps ); TextOut( hDC, 0, 0, _T("Hello world"), 11 ); EndPaint( &ps ); return 0; } LRESULT OnDestroy( UINT, WPARAM, LPARAM, BOOL& ){ PostQuitMessage( 0 ); return 0; } }; int APIENTRY WinMain( HINSTANCE hInstance, HINSTANCE, LPSTR, int ) { _Module.Init( NULL, hInstance ); CMyWindow wnd; wnd.Create( NULL, CWindow::rcDefault, _T("Hello"), WS_OVERLAPPEDWINDOW|WS_VISIBLE ); MSG msg; while( GetMessage( &msg, NULL, 0, 0 ) ){ TranslateMessage( &msg ); DispatchMessage( &msg ); } _Module.Term(); return msg.wParam; }
在这个示例程序中�Q�CmyWindow是从CWindowImpl�z��的，它的消息映射捕获了两个消息WM_PAINT和WM_DESTROY�Q�当收到WM_PAINT消息�Ӟ��它的成员函数OnPaint处理�q�个消息�q�在�H�口上输出“Hello world”，当收到WM_DESTROY消息�Ӟ��也就是当用户关闭�q�个�H�口的时候，调用OnDestroy函数处理�q�个消息�Q�在OnDestroy函数中调用PostQuitMessage来结束消息��@环�?

WinMain函数中创��Z��一个CmyWindow�cȝ��实例�q�实��C��一个标准的消息循环。（有一些地方，我们必须遵��@ATL的规范，比如在这里我们必��M��用_Module。）

消息映射�Q?
有三�l�用于消息映��的宏，他们分别是：
�H�口消息映射宏，用于所有的�H�口消息�Q�如WM_CREATE、WM_PAINT�{�）�Q?
命��o消息映射宏，专用于WM_COMMAND消息�Q�比如由控�g或菜单发出的消息�Q�；
通知消息映射宏，专用于WM_NOTUFY消息�Q�通常由通用控�g发出此消息，比如工具栏控件或列表视图控�g�Q?
�H�口消息映射宏：
有两个窗口消息映��宏�Q�他们分别是�Q?/p>
MESSAGE_HANDLER
MESSAGE_RANGE_HANDLER
�W�一个宏��一个特定的消息映射到相应的处理函数�Q�第二个宏将一�l�消息映��到一个处理函数。消息处理函数都要求��h��如下的原形：
LRESULT MessageHandler(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
其中�Q�参数uMsg是消息标识，wParam和lParam是两个附加与消息的参敎ͼ��Q�他们的具体意义取决与消息类别。）

消息处理函数使用bHandled来标志消息是否已�l�被完全捕获�Q�如果bHandled被设�|�成FALSE�Q�程序将�l�箋在消息映��表的后�l�部分查找这个消息的其它处理函数。这个特性��得我们对一个消息��用多个处理函数成为可能。什么时候需要对一个消息��用多个处理函数呢�Q�可能是在对多个�c�链接时�Q�也可能是我们只惛_��一个消息做出响应但是�ƈ不真正捕获它。在处理函数被调用之前，bHandled被置为TRUE�Q�所以如果我们不在函数的�l�尾昑ּ�地将它置为FALSE�Q�则消息映射表的后箋部分不会被��l�查找，也不会有其它的处理函数被调用�?

命��o消息映射宏：
命��o消息映射宏只处理命��o消息�Q�WM_COMMAND消息�Q�，但是它能让我们根据消息类型或者发送命令消息的控�gID来指定消息处理函数�?
COMMAND_HANDLER映射一个特定控件的一条特定消息到一个处理函敎ͼ�
COMMAND_ID_HANDLER映射一个特定控件的所有消息到一个处理函敎ͼ�
COMMAND_CODE_HANDLER映射��L��控�g的一个特定消息到一个处理函敎ͼ�
COMMAND_RANGE_HANDLER映射一定范围内的控件的所有消息到一个处理函敎ͼ�
COMMAND_RANGE_CODE_HANDLER映射一定范围内的控件的一条特定消息到一个处理函数�?
命��o消息处理函数应该��h��如下的原形：
LRESULT CommandHandler(WORD wNotifyCode, WORD wID, HWND hWndCtl, BOOL& bHandled);
其中�Q�参数wNotifyCode代表消息代码�Q�wID代表发送消息的控�g的ID�Q�hWndCtl代表发送消息的控�g的窗口句柄，bHandled的意义如前所�q��?

通知消息映射宏：
通知消息映射宏用来处理通知消息�Q�WM_NOTUFY消息�Q�，它根据通知消息的类型和发送通知消息的控件的不同��消息映��到不同的处理函敎ͼ��q�些宏与前面讲的命��o消息映射宏是�{��h的，唯一的不同就是它处理的是通知消息而不是命令消息�?
NOTIFY_HANDLER
NOTIFY_ID_HANDLER
NOTIFY_CODE_HANDLER
NOTIFY_RANGE_HANDLER
NOTIFY_RANGE_CODE_HANDLER
通知消息处理函数都需要如下的原�Ş�Q?/p>
LRESULT NotifyHandler(int idCtrl, LPNMHDR pnmh, BOOL& bHandled);
其中�Q�参数idCtrl代表发送通知消息的控件的ID�Q�参数pnmh是指向一个NMHDR�l�构的指针，bHandled的意义如前所�q��?

通知消息包含了一个指向消息细节的�l�构的指针，例如�Q�当一个列表视图控件发送一个通知消息�Q�这个消息就包含了一个指向NMLVDISPINFO�l�构的指针，所有类��g��NMLVDISPINFO的结构都包含一个NMHDR�l�构的头�Q�pnmh��指向这个头�Q�如果需要访问这�U�结构中头部以外的其它数据成员，可以��pnmh转化成相应类型的指针�?

例如�Q�我们如果要处理列表视图控�g发出的LVN_ENDLABELEDIT通知消息�Q�我们可以把下面�q�行代码攑ֈ�消息映射表中�Q?
NOTIFY_HANDLER( ID_LISTVIEW, LVN_ENDLABELEDIT, OnEndLabelEdit)
�q�个通知消息附带的额外信息包含在一个NMLVDISPINFO�l�构中，因此�Q�消息处理函数看��h��应该象下面这个样子：
LRESULT OnEndLabelEdit(int idCtrl, LPNMHDR pnmh, BOOL& bHandled) { // The item is -1 if editing is being canceled. if ( ((NMLVDISPINFO*)pnmh)->item.iItem == -1) return FALSE; ...
可以看出�Q�pnmh指针被�{化成NMLVDISPINFO*�c�d��Q�以便访问头部结构以外的数据�?

为现有的�H�口�c�L��加功能：
有许多向现有的窗口添加功能的�Ҏ��。如果这个类是ATL�H�口�c�，我们可以从这个窗口类�z��自己的类�Q�就象Base Class Chaining中描�q�的一栗��这�U�方法主要是一个C++�cȝ��l�承加上一�Ҏ��息映��的链接�?

如果我们��x��展一个预定义的窗口类�Q�如按纽�c�L��列表框类�Q�的功能�Q�我们可以超�c�d��它。就是创��Z��个基于这个预定义�cȝ��新类�Q��ƈ在消息映��表中添加消息映��以增强它的功能�?

有些时候，我们需要改变一个已�l�存在的�H�口实例的行为，而不是一个窗口类——或许我们要让一个对话框上的�~�辑框做点什么特别的事情。在�q�种情况下，我们可以写一个新的ATL�H�口�c�，�q�子�c�d��q�个已经存在的编辑框。�Q何本该发送到�q�个�~�辑框的消息都会先被发送到�q�个子类的对象�?

另外一�U�可选的�Ҏ��Q�我们也可以让这个编辑框成�ؓ一个被包含的窗口，所有发送到�q�个�~�辑框的消息都会�l�过它的容器�H�口�Q�我们可以在�q�个容器�H�口中�ؓ�q�个被包含的�H�口实现�Ҏ��的消息处理�?

最后的一�U�方法就是消息反��，当一个窗口收��C��个消息后不处理它�Q�而是反射�l�发送这个消息的�H�口自己处理�Q�这�U�技术可以用来创��包含的控件�?

基类消息链（Base Class Chaining�Q�：
如果我们已经有一些实��C��特定功能的ATL�H�口�c�，我们可以从它们派生新�c�M��充分利用�l�承的优炏V��比如：
class CBase: public CWindowImpl< CBase > // simple base window class: shuts down app when closed { BEGIN_MSG_MAP( CBase ) MESSAGE_HANDLER( WM_DESTROY, OnDestroy ) END_MSG_MAP() LRESULT OnDestroy( UINT, WPARAM, LPARAM, BOOL& ) { PostQuitMessage( 0 ); return 0; } }; class CDerived: public CBase // derived from CBase; handles mouse button events { BEGIN_MSG_MAP( CDerived ) MESSAGE_HANDLER( WM_LBUTTONDOWN, OnButtonDown ) END_MSG_MAP() LRESULT OnButtonDown( UINT, WPARAM, LPARAM, BOOL& ) { ATLTRACE( "button down\n" ); return 0; } }; // in WinMain(): ... CDerived win; win.Create( NULL, CWindow::rcDefault, "derived window" );
可是�Q�上面的代码有一个问题。当我们在调试模式下�q�行�q�个�E�序�Q�一个窗口出��C��Q�如果我们在�q�个�H�口中单击，“button down”将出现在输出窗口中�Q�这是CDrived�cȝ��功能�Q�可是，当我们关闭这个窗口的时候，�E�序�q�不退出，��管CBase�c�d��理了WM_DESTROY消息�q�且CDrived�c�L��从CBase�c�L��生的�?

Why�Q�因为我们必��L��地��一个消息映��表链接到另外一个。如下：
BEGIN_MSG_MAP( CDerived ) MESSAGE_HANDLER( WM_LBUTTONDOWN, OnButtonDown ) CHAIN_MSG_MAP( CBase ) // 链接到基�c? END_MSG_MAP()
现在�Q��Q何在CDrived�c�M��没有被处理的消息都会被传到CBase�c�M��?

��Z��么不自动��派生类的消息映��和它的基类的消息映��链接�v来呢�Q�这是因为在ATL的体�pȝ��构中有很多多重��承的情况�Q�这�U�情况下没有办法知道�I�竟应该链接到哪个基�c�，所以只好让�E�序员自己来做决定�?

可选的消息映射�Q?
消息映射铑օ�许多个类同时�q�行消息处理�Q�同时也带来了问题：如果我们在多个类中都要响应WM_CREATE消息�Q�但是不同的�c�需要基�c�L��供不同的处理�Q�怎么办呢�Q��ؓ了解册��个问题，ATL使用了可选的消息映射�Q�将消息映射表分成很多节�Q�每一节用不同的数字标识，每一节都是一个可选的消息映射表�?
// in class CBase: BEGIN_MSG_MAP( CBase ) MESSAGE_HANDLER( WM_CREATE, OnCreate1 ) MESSAGE_HANDLER( WM_PAINT, OnPaint1 ) ALT_MSG_MAP( 100 ) MESSAGE_HANDLER( WM_CREATE, OnCreate2 ) MESSAGE_HANDLER( WM_PAINT, OnPaint2 ) ALT_MSG_MAP( 101) MESSAGE_HANDLER( WM_CREATE, OnCreate3 ) MESSAGE_HANDLER( WM_PAINT, OnPaint3 ) END_MSG_MAP()
如上�Q�基�cȝ��消息映射表由3节组成：一个默认的消息映射表（隐含的标识�ؓ0�Q�和两个可选的消息映射表（标识�?00�?01�Q��?

当你链接消息映射表时�Q�指定你所希望的方案的标识�Q�如下：
class CDerived: public CBase { BEGIN_MSG_MAP( CDerived ) CHAIN_MSG_MAP_ALT( CBase, 100 ) END_MSG_MAP() ...
CDrived�cȝ��消息映射表链接到CBase�c�M��标识号�ؓ100的可选节�Q�因此当WM_PAINT到达�Ӟ��CBase::OnPaint2被调用�?
�Q�译者注�Q�我觉得�q�种�Ҏ��不太合乎C++的思想�Q�基�cȝ��~�写者不一定总能知道�z��自它的类会有哪些需求，而且把所有不同的版本都在基类中实玎ͼ�基类中无用的代码量会大大增加。更好的办法应该是把基类中的消息处理函数声明��函数。��M��Q�我觉得�q�一��节�q�不能体现出可选消息映��的真正用途。）

其它�c�d��的链�Q?
除了基类消息映射链，ATL也提供了成员链（member chaining�Q�和动态链(dynamic chaining)�Q�这些很��用到的链技术超��Z��我们�q�篇文章的讨��_��但是可以��单提一下。成员链允许把消息映��链接到一个类的成员变量，动态链允许在运行时�q�行动态链接。如果你想了解更多，请参考ATL文档中的CHAIN_MSG_MAP_DYNAMIC 和CHAIN_MSG_MAP_MEMBER的相兛_��宏V�?

�H�口的超�c�d��Q?/strong>
��类化定义一个类�Q��ƈ为预定义的窗口类�Q�如按钮�c�L��列表框类�Q�添加新的功能，下面的例子超�c�d��一个按钮，让这个按钮在被单�ȝ��时候发��鸣�?
class CBeepButton: public CWindowImpl< CBeepButton > { public: DECLARE_WND_SUPERCLASS( _T("BeepButton"), _T("Button") ) BEGIN_MSG_MAP( CBeepButton ) MESSAGE_HANDLER( WM_LBUTTONDOWN, OnLButtonDown ) END_MSG_MAP() LRESULT OnLButtonDown( UINT, WPARAM, LPARAM, BOOL& bHandled ) { MessageBeep( MB_ICONASTERISK ); bHandled = FALSE; // alternatively: DefWindowProc() return 0; } }; // CBeepButton
DECLARE_WND_SUPERCLASS宏声明了�q�个�H�口的类名（“BeepButton”）和被��类化的�c�d��Q�“Button”）。它的消息映��表只有一个入口项�Q�将WM_LBUTTONDOWN消息映射到OnLButtonDown函数。其余的消息都让默认的窗口过�E�处理，除了可以发出蜂鸣外，CbeepButton需要和其它的按钮表现相同，因此在OnLButtonDown函数的最后，需要将bHandled讄��为FALSE�Q�让默认的窗口过�E�在OnLButtonDown函数完成后对WM_LBUTTONDOWN消息�q�行其它的处理。（另外的一�U�方法是直接调用DefWindowProc函数。）

到目前�ؓ止，我们所做的只是定义了一个新�c�；我们依然需要创��Z��些真正的CbeepButton�H�口�Q�下面的�c�d��义了两个CbeepButton�c�d��的成员变量，因此�Q�当�q�个�cȝ��H�口被创建时�Q�将会创��Z��个CbeepButton�c�d��的子�H�口�?
const int ID_BUTTON1 = 101; const int ID_BUTTON2 = 102; class CMyWindow: public CWindowImpl< CMyWindow, CWindow, CWinTraits > { CBeepButton b1, b2; BEGIN_MSG_MAP( CMyWindow ) MESSAGE_HANDLER( WM_CREATE, OnCreate ) COMMAND_CODE_HANDLER( BN_CLICKED, onClick ) END_MSG_MAP() LRESULT onClick(WORD wNotifyCode, WORD wID, HWND hWndCtl, BOOL& bHandled) { ATLTRACE( "Control %d clicked\n", wID ); return 0; } LRESULT OnCreate( UINT, WPARAM, LPARAM, BOOL& ) { RECT r1 = { 10, 10, 250, 80 }; b1.Create(*this, r1, "beep1", WS_CHILD|WS_VISIBLE, 0, ID_BUTTON1); RECT r2 = { 10, 110, 250, 180 }; b2.Create(*this, r2, "beep2", WS_CHILD|WS_VISIBLE, 0, ID_BUTTON2); return 0; } }; // CMyWindow
�H�口的子�c�d��Q?/strong>

子类化允许我们改变一个已�l�存在的�H�口的行为，我们�l�常用它来改变控件的行�ؓ。它的实现机制是插入一个消息映��表来截取发向控件的消息。�D例说明：假设有一个对话框�Q�对话框上有一个编辑框控�g�Q�我们想让这个控件只接受不是数字的字�W�。我们可以截获发往�q�个控�g的WM_CHAR消息�q�抛弃接收到的数字字�W�。下面的�c�d��现这个功能：
class CNoNumEdit: public CWindowImpl< CNoNumEdit > { BEGIN_MSG_MAP( CNoNumEdit ) MESSAGE_HANDLER( WM_CHAR, OnChar ) END_MSG_MAP() LRESULT OnChar( UINT, WPARAM wParam, LPARAM, BOOL& bHandled ) { TCHAR ch = wParam; if( _T(''0'') <= ch && ch <= _T(''9'') ) MessageBeep( 0 ); else bHandled = FALSE; return 0; } };
�q�个�c�d��处理一个消息WM_CHAR�Q�如果这个字�W�是数字的话�Q�则调用MessageBeep( 0 )�q�返回，�q�样可以有效地忽略这个字�W�。如果不是数字，则将bHandled讄��为FALSE�Q�指明默认的�H�口�q�程�q�个消息需要进一步处理�?

现在我们��子�c�d��一个编辑框控�g�Q�以便CnoNumEdit能够抢先处理发到�q�个�~�辑框得消息。（下面得例子用��C��CdialogImpl�c�，�q�个�c�L��们将在ATL中的对话框类一节中介绍。）在这个例子中�Q�CmyDialog�c�M��用到了一个对话框资源�Q�ID号�ؓIDD_DIALOG1�Q�，对话框中有一个编辑框控�g�Q�ID号�ؓIDC_EDIT1�Q�，当对话框初始化的时候，�~�辑框经�q�SubclassWindow而变成一个不接受数字的编辑框�Q?
class CMyDialog: public CDialogImpl { public: enum { IDD = IDD_DIALOG1 }; BEGIN_MSG_MAP( CMyDialog ) MESSAGE_HANDLER( WM_INITDIALOG, OnInitDialog ) END_MSG_MAP() LRESULT OnInitDialog( UINT, WPARAM, LPARAM, BOOL& ) { ed.SubclassWindow( GetDlgItem( IDC_EDIT1 ) ); return 0; } CNoNumEdit ed; };

　

文章引用�? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvc60/html/atlwindow.asp

jay 2007-03-13 09:52 发表评论

jay — Mon, 12 Mar 2007 13:29:00 GMT

��h��?/b>

    在本文的�W�一部分�Q�我们简要介�l�了ATL的一些背景知识以及ATL所面向的开发技术和环境。在�q�一部分 ��开始走�q�ATL�Q�讲�q�ATL�~�程的基本方法、原则和必须要注意的问题�?br />    理解ATL最�Ҏ��的方法是考察它对客户端编�E�的支持。对于COM�~�程新手而言�Q�一个棘手的主要问题之一是正��管理接口指针的引用计数。COM的引用计数法则是没有�q�行时强�?性的�Q�也��是说每一个客��L��必须保证对对象的承诺�?br />    有经验的COM�~�程者常�怹�惯于使用文档中（如《Inside OLE》）提出的标准模式。调用某个函数或�Ҏ��Q�返回接口指针，在某个时间范围内使用�q�个接口指针�Q�然后释攑֮�。下面是使用�q�种模式的代码例子：

void f(void) { IUnknown *pUnk = 0; // 调用 HRESULT hr = GetSomeObject(&pUnk); if (SUCCEEDED(hr)) { // 使用 UseSomeObject(pUnk); // 释放 pUnk->Release(); } }
    �q�个模式在COM�E�序员心中是如此�Ҏ��蒂固�Q�以至于他们常常不写实际使用指针的语句，而是先在代码块末��敲入Release语句。这很像C�E�序员��用switch语句时的条�g反射一��P��先敲入break再说�?br />    其实调用Release实在不是什么可怕的负担�Q�但是，客户端程序员面��两个相当严重的问题。第一个问题与获得多接口指针有兟뀂如果某个函数需要在做�Q何实际工作之前获得三个接口指针，也就是说在第一个��用指针的语句之前必须要由三个调用语句。在书写代码�Ӟ��q�常常意味着�E�序员需要写许多嵌套条�g语句�Q�如�Q?br />
void f(void) { IUnknown *rgpUnk[3]; HRESULT hr = GetObject(rgpUnk); if (SUCCEEDED(hr)) { hr = GetObject(rgpUnk + 1); if (SUCCEEDED(hr)) { hr = GetObject(rgpUnk + 2); if (SUCCEEDED(hr)) { UseObjects(rgpUnk[0], rgpUnk[1], rgpUnk[2]); rgpUnk[2]->Release(); } rgpUnk[1]->Release(); } rgpUnk[0]->Release(); } }
    像这��L��语句常常促�ɽE�序员将TAB键设�|�成一个或两个�I�格�Q�甚��x��愿��用大一点的昄��器。但事情�q�不��L��按你惌��的那��P��׃��U�种原因��目团队中的COM�l��g�~�程人员往往得不�?所想的��g支持�Q�而且在公司确定关于TAB键的使用标准之前�Q�程序员常常求助于��用有很大争议但仍然有效的“GOTO”语句：
void f(void) { IUnknown *rgpUnk[3]; ZeroMemory(rgpUnk, sizeof(rgpUnk)); if (FAILED(GetObject(rgpUnk))) goto cleanup; if (FAILED(GetObject(rgpUnk+1))) goto cleanup; if (FAILED(GetObject(rgpUnk+2))) goto cleanup; UseObjects(rgpUnk[0], rgpUnk[1], rgpUnk[2]); cleanup: if (rgpUnk[0]) rgpUnk[0]->Release(); if (rgpUnk[1]) rgpUnk[1]->Release(); if (rgpUnk[2]) rgpUnk[2]->Release(); }
�q�样的代码虽然不那么专业�Q�但臛_��减少了屏�q�的水��^滚动�?br />使用以上�q�些代码�D�|��在着更加��手的问题，那就是在��到C++异常时。如果函数UseObjects丢出异常�Q�则释放指针的代码被完全屏蔽掉了�?解决�q�个问题的一个方法是使用Win32的结构化异常处理�Q�SEH�Q�进行终�l�操作：
void f(void) { IUnknown *rgpUnk[3]; ZeroMemory(rgpUnk, sizeof(rgpUnk)); __try { if (FAILED(GetObject(rgpUnk))) leave; if (FAILED(GetObject(rgpUnk+1))) leave; if (FAILED(GetObject(rgpUnk+2))) leave; UseObjects(rgpUnk[0], rgpUnk[1], rgpUnk[2]); } __finally { if (rgpUnk[0]) rgpUnk[0]->Release(); if (rgpUnk[1]) rgpUnk[1]->Release(); if (rgpUnk[2]) rgpUnk[2]->Release(); }
    可惜Win32 SHE在C++中的表现�q�不如想象得那么好。较好的�Ҏ��是��用内建的C++异常处理模型�Q�同时停止��用没有加工过的指针。标准C++库有一个类�Q�auto_ptr�Q�在其析构函��C��?��M��一个操作指针的delete调用�Q�即使在出现异常时也能保证调用）。与之类��|��ATL有一个COM��指针�Q�CComPtr�Q�它的析构函��C��正确调用Release�?br />    CComPtr�c�d��现客��L��基本的COM引用计数模型。CComPtr有一个数据成员，它是一个未�l�过��M��加工的COM接口指针。其�c�d��被作为模板参��C��递：
CComPtr unk; CComPtr cf;
    �~�省的构造函数将�q�个原始指针数据成员初始化�ؓNULL。智能指针也有构造函敎ͼ�它的参数要么是原始指针，要么是相同类型的��参数。不论哪�U�情况，��指针都调用AddRef控制引用。CComPtr的赋值操作符既可以处理原始指针，也可以处理智能指针，�q�且在调用新分配指针的AddRef之前自动释放保存的指针。最重要的是�Q�CComPtr的析构函数释放保存的接口�Q�如果非�I�）。请看下列代码：
void f(IUnknown *pUnk1, IUnknown *pUnk2) { // 如果非空�Q�构造函数调用pUnk1的AddRef CComPtr unk1(pUnk1); // 如果非空�Q�构造函数调用unk1.p的AddRef CComPtr unk2 = unk1; // 如果非空�Q�operator= 调用unk1.p的Release�q�且 //如果非空�Q�调用unk2.p的AddRef unk1 = unk2; //如果非空�Q�析构函数释放unk1 �?unk2 }
    除了正确实现COM的AddRef �?Release规则之外�Q�CComPtr�q�允许实现原始和��指针的透明操作�Q�参�?a >附表�?/a>所�C�。也��是说下面的代码按照你所惌��的方式运行：
void f(IUnknown *pUnkCO) { CComPtr cf; HRESULT hr; // 使用操作�W?& 获得�?&cf.p 的存�? hr = pUnkCO->QueryInterface(IID_IClassFactory,(void**)&cf); if (FAILED(hr)) throw hr; CComPtr unk; // 操作�W?-> 获得对cf.p的存�? // 操作�W?& 获得�?&unk.p的存�? hr = cf->CreateInstance(0, IID_IUnknown, (void**)&unk); if (FAILED(hr)) throw hr; // 操作�W?IUnknown * �q�回 unk.p UseObject(unk); // 析构函数释放unk.p �?cf.p }
    除了�~�Z��对Release的显式调用外�Q�这�D�代码像是纯�_�的COM代码。有了CComPtr�cȝ��武装�Q�前面所遇到的麻烦问题顿时变得简单了�Q?br />
void f(void) {
CComPtr rgpUnk[3];
if (FAILED(GetObject(&rgpUnk[0]))) return;
if (FAILED(GetObject(&rgpUnk[1]))) return;
if (FAILED(GetObject(&rgpUnk[2]))) return;
UseObjects(rgpUnk[0], rgpUnk[1], rgpUnk[2]);
}
�׃��CComPtr�Ҏ��作符重蝲用法的扩展，使得代码的编译和�q�行无懈可击�?br />    假定模板�cȝ��道它所操纵的指针类型，你可能会问：那�ؓ什么智能指针不能在它的功能操作�W�或构造函��C��自动调用QueryInterface�Q�从而更有效地包装IUnknown呢？在Visual C++ 5.0出来以前�Q�没有办法将某个接口的GUID与它的本�w�的C++�c�d��兌��h��——Visual C++ 5.0用私有的declspec��某个IID与一个接口定义绑定在一赗��因为ATL的设�?考虑��C��它要与大量不同的C++�~�译器一起工作，它需要用与编译器无关的手�D�|��供GUID。下面我们来探讨另一个类——CComQIPtr�c�R�?br />    CComQIPtr与CComPtr关系很密切（实际上，它只增加了两个成员函敎ͼ�。CComQIPtr必须要两个模板参敎ͼ�一个是被操�U늚�指针�c�d�� Q�另一个是对应于这个指针类型的GUID。例如，下列代码声明了操�U�IDataObject 和IPersist接口的智能指针：
CComQIPtr do; CComQIPtr p;
    CComQIPtr的优�Ҏ��它有重蝲的构造函数和赋值操作符。同�cȝ��本（例如�Q�接受相同类型的接口�Q�仅仅AddRef双��的赋�?初始化操作。这实际上就是CComPtr的功能。异�cȝ��本（接受�c�d��不一致的接口�Q�正��调用QueryInterface来决定是否这个对象确实支持所��h��的接口：
void f(IPersist *pPersist) { CComQIPtr p; // 同类赋�?- AddRef''s p = pPersist; CComQIPtr do; // 异类赋�?- QueryInterface''s do = pPersist; }
    在第二种赋��D��句中�Q�因为pPersist是非IDataObject *�c�d��Q�但它是�z��于IUnknown的接口指针，CComQIPtr通过pPersist调用QueryInterface来试图获得这个对象的IDataObject接口指针。如果QueryInterface调用成功�Q�则此智能指针将含有作�ؓ�l�果的原始IDataObject指针。如果QueryInterface调用��p�|�Q�则do.p��被�|��ؓnull。如果QueryInterface�q�回的HRESULT值很重要�Q�但又没有办法从赋值操作获得其值时�Q�则必须昑ּ�调用QueryInterface�?br />    既然有了CComQIPtr�Q�那��Z��么还要CComPtr呢？由几个理由：首先�Q�ATL最初的发布版本只支持CComPtr�Q�所以它��׃��直合法地保留下来了。其二（也是最重要的理由）�Q�由于重载的构造函数和赋值操作，对IUnknown使用CComQIPtr是非法的。因为所有COM接口的类型定义都必须与IUnknown兼容�?br />
CComPtr unk;
从功能上��它�{�同�?
CComQIPtr unk;
前者正��。后者是错误的用法。如果你�q�样写了�Q�C++�~�译器将提醒你改正�?br />    ��CComPtr作�ؓ首选的另外一个理由可能是一些开发�h员相信静悄悄地调用QueryInterface�Q�没有警告，削弱了C++�pȝ��的类型。毕竟，C++在没有进行强制类型�{换的情况下不允许对类型不一致的原始指针 �q�行赋值操作，所以�ؓ什么要用智能指针的道理也在�q�，�q�运的是开发�h员可以选择最能满��需要的指针�c�d��?br />    许多开发�h员将��指针看成是对�q�于的复杂编�E��Q务的��化。我最初也是这么认为的。但只要留意它们使用COM��指针的方法。就会逐渐认识到它们引入的潜在危险与它们解决的问题一样多�?br />关于�q�一点，我用一个现成的使用原始指针的函��Cؓ例：
void f(void) { IFoo *pFoo = 0; HRESULT hr = GetSomeObject(&pFoo); if (SUCCEEDED(hr)) { UseSomeObject(pFoo); pFoo->Release(); } }
��它自然而然转换��C��用CComPtr�?br />
void f(void) { CComPtr pFoo = 0; HRESULT hr = GetSomeObject(&pFoo); if (SUCCEEDED(hr)) { UseSomeObject(pFoo); pFoo->Release(); } }
    注意CComPtr �?CComQIPtr输出所有受控接口成员，包括AddRef和Release。可惜当客户端通过操作�W?>的结果调用Release�Ӟ��指针很健�?�Q�会二次调用构造函��C��的Release。显然这是错误的�Q�编译器和链接器也欣然接受了�q�个代码。如果你�q�气好的话，调试器会很快捕获到这个错误�?br />    使用ATL��指针的另一个要引�v注意的风险是�c�d��强制转换操作�W�对原始指针提供的访问。如果隐式强制�{换操作符的��用存在争议。当 ANSI/ISO C++ 委员会在军_��采用某个C++串类�Ӟ��他们明确��止隐式�c�d��转换。而是要求必须昑ּ�使用c_str函数在需要常量char *�Q�const char *�Q�的地方传递标准C++丌Ӏ�ATL提供了一�U�隐含式的类型�{换操作符��利地解决了�q�个问题。通常�Q�这个�{换操作符可以�Ҏ��你的喜好来��用，允许你将��指针传递到需要用原始指针的函数�?br />
void f(IUnknown *pUnk) { CComPtr unk = pUnk; // 隐式调用操作�W�IUnknown *() CoLockObjectExternal(unk, TRUE, TRUE); }
�q�段代码能正��运行，但是下面的代码也不会产生警告信息�Q�编译正帔R��过�Q?
HRESULT CFoo::Clone(IUnknown **ppUnk) { CComPtr unk; CoCreateInstance(CLSID_Foo, 0, CLSCTX_ALL, IID_IUnknown, (void **) &unk); // 隐式调用操作�W�IUnknown *() *ppUnk = unk; return S_OK; }
    在这�U�情况下�Q�智能指针（unk�Q�对原始值针**ppUnk的赋��D��发了与前面代码段相同的强制类型�{换。在�W�一个例子中�Q�不需要用AddRef。在�W�二个例子中�Q�必��要用AddRef�?br />    有关使用��指针的更详细一般信息，请参见Scott Meyer的《More Effective C++》（Addison-Wesley, 1995�q�出版）。国内目前还没有�q�本书的中译本或影印本。有关COM��指针的更多特定信息，请参见Don Box的一��关于智能指针的专题文章http://www.develop.com/dbox/cxx/SmartPointer.htm�?�Q�待�l�）

jay 2007-03-12 21:29 发表评论

CComPtr �?CComQIPtr

jay — Mon, 12 Mar 2007 03:39:00 GMT

对于操作原始的接口指针是比较�ȝ��的，需要我们自己控制引用记数、API 调用、异常处理。于�?ATL 提供�?/p>
2个智能指针的模板包装�c�，CComPtr<> �?CComQIPtr<>�Q�这两个�c�都�? 中声明。CComQIPtr<>

包含�?CComPtr<>的所有功能，因此我们可以完全�?CComQIPtr<> 来��用智能接口指针，唯一要说明的一点就

是：CComQIPtr<> �׃��使用了运��符的重载功能，它会自动帮我们调用QueryInterface()函数�Q�因�?

CComQIPtr<> 唯一的缺点就是不能定�?IUnknown * 指针�?/p>
　　 // ��指针 smart pointer�Q�按照匈牙利命名法，一般以 sp 开头来表示变量�c�d��
　　 CComPtr < IUnknown > spUnk; // 正确
　　 // 假设 IFun 是一个接口类�?br />　　 CComPtr < IFun > spFun; // 正确
　　 CComQIPtr < IFun > spFun; // 正确
　　 CComQIPtr < IFun, &IID_IFun > spFun; // 正确
　　 CComQIPtr < IUnknown > spUnk; // 错误�Q�CComQIPtr不能定义IUnknown指针
�l�智能指针赋值的�Ҏ��Q�　　 CComQIPtr < IFun > spFun; // 调用构造函敎ͼ��q�没有赋��|��被包装的内部

接口指针�?NULL
　　
　　 CComQIPtr < IFun > spFun( pOtherInterface ); // 调用构造函敎ͼ�内部接口指针赋��gؓ
　　 // 通过 pOtherInterface �q�个普通接口指针调用QueryInterface()得到的IFun接口指针
　　
　　　　
　　 CComQIPtr < IFun > spFun ( pUnknown ); // 调用构造函敎ͼ�由IUnknown的QueryInterface()得到

IFun接口指针
　　
　　 CComQIPtr < IFun > spFun = pOtherInterface; // = �q�算�W�重载，含义和上面一�?br />　　 spFun = spOtherInterface; // 同上
　　 spFun = pUnknown; // 同上
　　
　　 pUnknown->QueryInterface( IID_IFun, &sp ); // 也可以通过QueryInterface赋�?br />　　
　　 // ��指针赋值后�Q�可以用条�g语句判断是否合法有效
　　 if ( spFun ){}  // 如果指针有效
　　 if ( NULL != spFun ){} // 如果指针有效
　　
　　 if ( !spFun ){}  // 如果指针无效
　　 if ( NULL == spFun ){} // 如果指针无效
��指针调用函数的方法：　　 spFun.CoCreateInstance(...); // �{��h�?API

函数::CoCreateInstance(...)
　　 spFun.QueryInterface(...); // �{��h�?API 函数::QueryInterface()
　　
　　 spFun->Add(...); // 调用内部接口指针的接口函�?/p>
　　 // 调用内部接口指针的QueryInterface()函数�Q�其实效果和 spFun.QueryInterface(...) 一�?br />　　 spFun->QueryInterface(...);
　　
　　 spFun.Release(); // 释放内部的接口指针，同时内部指针赋��gؓ NULL
　　 spFun->Release(); // 错！�Q�！一定不要这么��用�?br />　　 // 因�ؓ�q�个调用�q�不把内部指针清�I�，那么析构的时候会被再�ơ释放（释放了两�ơ）

jay 2007-03-12 11:39 发表评论

jay — Mon, 12 Mar 2007 03:01:00 GMT

一、前�a�

　　上两回中�Q�咱们用 ATL 写了�W�一�?COM �l��g�E�序�Q�这回中�Q�主要介�l�编译、注册和调用�Ҏ��。示例程序你已经下蝲了吗�Q�如果还没有下蝲�Q�vc6.0 的用��L��q�里�Q�vc.net 的用��L��q�里�?b>

二、关于编�?br />
　　2-1 最��依�?/i>
　　“最��依赖”，表示�~�译器会�?ATL 中必��M��用的一些函数静态连接到目标�E�序中。这��L��标文件尺�怼��E�大�Q�但独立性更强，安装方便�Q�反之系�l�执行的时候需要有 ATL.DLL 文�g的支持。如何选择讄��为“最��依赖”呢�Q�答案是�Q�删除预定义宏“_ATL_DLL”，操作�Ҏ��见图一、图二�?br />

图一、在vc6.0中，讄��Ҏ��

图二、在 vc.net 2003中，讄��Ҏ��

　　2-2 CRT�?/b>
　　如果�?ATL �l��g�E�序中调用了 CRT 的运行时��d��函数�Q�比如开�q�x�� sqrt() �Q�那么编译的时候可能会报错“error LNK2001: unresolved external symbol _main”。怎么办？删除预定义宏“_ATL_MIN_CRT”！操作�Ҏ��也见图一、图二。（vc.net 2003 中的�q�个��目属性叫“在 ATL 中最��?CRT”）

　　2-3 MBCS/UNICODE
　　�q�个不多说了�Q�在预定义宏中，分别使用 _MBCS �?_UNICODE�?br />
　　2-4 IDL 的编�?/b>
　　COM 在设计初期，��定了一个目标：要能实现跨语�a�的调用。既然是跨语�a�的，那么�l��g的接口描�q�就必须在�Q何语�a�环境中都要能够认识。怎么办？�?.h 文�g描述�Q?----- C语言�E�序员笑了，真方便！BASIC �E�序员哭�?-( 因此�Q�微软��用了一个新的文件格�?--IDL文�g�Q�接口定义描�q�语�a��Q�。IDL 是一个文本文�Ӟ��它的语言语法比较��单，很象C。具�?IDL 文�g的讲解，见下一回《COM �l��g设计与应用（八）之添加新接口》。IDL �l�过�~�译�Q�生成二�q�制的等��L��型库文�g TLB 提供�l�其它语�a�来��用。图三示意了 ATL COM �E�序�~�译的过�E�：

图三、ATL �l��g�E�序�~�译�q�程

　　说明1�Q�编译后�Q�类型库�?TLB 文�g形式单独存在�Q�同时也保存在目标文件的资源中。因此，我们��来�?#import 引入�c�d��库的时候，既可以指�?TLB 文�g�Q�也可以指定目标文�g�Q?br />　　说明2�Q�我们作�?C/C++ 的程序员�Q�还��是比较�q�福的。因�?IDL �~�译后，�Ҏ��为我们提供了 C 语言形式的接口文件�?br />　　说明3�Q�IDL �~�译后生成代�?存根源程序，有：dlldata.c、xxx_p.c、xxxps.def、xxxps.mak�Q�我们可以用 NMAKE.EXE 再次�~�译来��生真正的代理/存根DLL目标文�g(�?)�?br />

三、关于注�?br />
　　情况1�Q?/i>当我们��?ATL �~�写�l��g�E�序�Q�注册不用我们来负责。编译成功后�Q�IDE 会帮我们自动注册�Q?br />　　情况2�Q?/b>当我们��?MFC �~�写�l��g�E�序�Q�由于编译器不知道你写的是否�?COM �l��g�Q�所以它不会帮我们自动注册。这个时候，我们可以执行菜单“Tools\Register Control”来注册�?br />　　情况3�Q?/b>当我们写一个具�?COM 功能�?EXE �E�序�Ӟ��注册的方法就是运行一�ơ这个程序；
　　情况4�Q?/b>当我们需要��用第三方提供的组件程序时�Q�可以命令行�q�行“regsvr32.exe 文�g名”来注册。顺便说一句，反注册的�Ҏ��是“regsvr32.exe /u 文�g名”；
　　情况5�Q?/b>当我们需要在�E�序中（比如安装�E�序�Q�需要执行注册，那么�Q?/p>
typedef HRESULT (WINAPI * FREG)(); TCHAR szWorkPath[ MAX_PATH ]; ::GetCurrentDirectory( sizeof(szWorkPath), szWorkPath ); // 保存当前�q�程的工作目�? ::SetCurrentDirectory( �l��g目录 ); // 切换到组件的目录 HMODULE hDLL = ::LoadLibrary( �l��g文�g�?); // 动态装载组�? if(hDLL) { FREG lpfunc = (FREG)::GetProcAddress( hDLL, _T("DllRegisterServer") ); // 取得注册函数指针 // 如果是反注册�Q�可以取�?DllUnregisterServer"函数指针 if ( lpfunc ) lpfunc(); // 执行注册。这里�ؓ了简单，没有判断�q�回�? ::FreeLibrary(hDLL); } ::SetCurrentDirectory(szWorkPath); // 切换回原先的�q�程工作目录
　　上面的示例，在多数情况下可以��化掉切换工作目录的代码部分。但是，如果�q�个�l��g在装载的时候，它需要同时加载一些必��M��赖的DLL�Ӟ��有可能由于它自��n�E�序�?BUG ��D��无法正确定位。咳......�q�是让我们自己写的程序，来��I补它的错误吧......谁让�׃��是好人呢 �Q�谁让咱们的水��^比他高呢�Q�谁让咱们在 vckbase 上是个“榜眼”呢......

四�?/b>关于�l��g调用

　　�ȝ��来说�Q�调用组件程序大概有如下�Ҏ��Q?br />　
#include �Ҏ�� IDL�~�译后，为方便C/C++�E�序员的使用�Q�会产生xxx.h和xxx_i.c文�g。我们真�q�福�Q�直�?include后就可以使用�?/td>
#import �Ҏ�� 比较通用的方法，vc 会帮我们产生包装�c�，让我们的调用更方�?/td>
加蝲�c�d��库包装类 �Ҏ�� 如果�l��g提供�?IDispatch 接口�Q�用�q�个�Ҏ��调用�l��g是最��单的啦。不�q�还没讲IDispatch�Q�只能看以后的文章啦
加蝲ActiveX包装�c?�Ҏ�� ActiveX �q�没介绍呢，以后再说�?/td>
　　下蝲�C�Z��E�序后，请逐项��览使用�Ҏ��Q?/p>
�C�Z��
�Ҏ��
��要说�?/b>
1 #include 完全用最基本�?API 方式调用�l��g�Q��大家熟悉调用原理
2 #include 大部分��?API 方式�Q��?CComBSTR ��化对字符串的使用
3 #include 展示��指针 CComPtr<> 的��用方�?/td>
4 #include 展示��指针 CComPtr<> �?CComQIPtr<> 混合的��用方�?/td>
5 #include 展示��指针 CComQIPtr<> 的��用方�?/td>
6 #include 展示��指针的释放方�?/td>
7 #import vc 包装的智能指�?IxxxPtr、_bstr_t、_variant_t 的��用方法和异常处理
8 #import import 后的命名�I�间的��用方�?/td>
　　�C�Z��E�序中都写有注释�Q�请读者仔�l�阅��dƈ同时参�?MSDN 的函数说明。这里，我给大家介绍一下“智能指针”：
　　对于操作原始的接口指针是比较�ȝ��的，需要我们自己控制引用记数、API 调用、异常处理。于�?ATL 提供�?个智能指针的模板包装�c�，CComPtr<> �?CComQIPtr<>�Q�这两个�c�都�? 中声明。CComQIPtr<> 包含�?CComPtr<>的所有功能，因此我们可以完全�?CComQIPtr<> 来��用智能接口指针，唯一要说明的一点就是：CComQIPtr<> �׃��使用了运��符的重载功能，它会自动帮我们调用QueryInterface()函数�Q�因�?CComQIPtr<> 唯一的缺点就是不能定�?IUnknown * 指针�?/p>
　　 // ��指针 smart pointer�Q�按照匈牙利命名法，一般以 sp 开头来表示变量�c�d�� 　　 CComPtr < IUnknown > spUnk; // 正确　　 // 假设 IFun 是一个接口类�? 　　 CComPtr < IFun > spFun; // 正确　　 CComQIPtr < IFun > spFun; // 正确　　 CComQIPtr < IFun, &IID_IFun > spFun; // 正确　　 CComQIPtr < IUnknown > spUnk; // 错误�Q�CComQIPtr不能定义IUnknown指针
�l�智能指针赋值的�Ҏ��Q?pre>　　 CComQIPtr < IFun > spFun; // 调用构造函敎ͼ��q�没有赋��|��被包装的内部接口指针�?NULL 　　　　 CComQIPtr < IFun > spFun( pOtherInterface ); // 调用构造函敎ͼ�内部接口指针赋��gؓ 　　 // 通过 pOtherInterface �q�个普通接口指针调用QueryInterface()得到的IFun接口指针　　　　 CComQIPtr < IFun > spFun( spOtherInterface ); // 调用构造函敎ͼ�内部接口指针赋��gؓ 　　 // 通过 spOtherInterface �q�个只能接口指针调用QueryInterface()得到的IFun接口指针　　　　 CComQIPtr < IFun > spFun ( pUnknown ); // 调用构造函敎ͼ�由IUnknown的QueryInterface()得到IFun接口指针　　　　 CComQIPtr < IFun > spFun = pOtherInterface; // = �q�算�W�重载，含义和上面一�? 　　 spFun = spOtherInterface; // 同上　　 spFun = pUnknown; // 同上　　　　 pUnknown->QueryInterface( IID_IFun, &sp ); // 也可以通过QueryInterface赋�? 　　　　 // ��指针赋值后�Q�可以用条�g语句判断是否合法有效　　 if ( spFun ){} // 如果指针有效　　 if ( NULL != spFun ){} // 如果指针有效　　　　 if ( !spFun ){} // 如果指针无效　　 if ( NULL == spFun ){} // 如果指针无效��指针调用函数的方法：
　　 spFun.CoCreateInstance(...); // �{��h�?API 函数::CoCreateInstance(...) 　　 spFun.QueryInterface(...); // �{��h�?API 函数::QueryInterface() 　　　　 spFun->Add(...); // 调用内部接口指针的接口函�? 　　 // 调用内部接口指针的QueryInterface()函数�Q�其实效果和 spFun.QueryInterface(...) 一�? 　　 spFun->QueryInterface(...); 　　　　 spFun.Release(); // 释放内部的接口指针，同时内部指针赋��gؓ NULL 　　 spFun->Release(); // 错！�Q�！一定不要这么��用�? 　　 // 因�ؓ�q�个调用�q�不把内部指针清�I�，那么析构的时候会被再�ơ释放（释放了两�ơ）
�?.....不说了，不说了，大家多看书，多看MSND�Q�多看示例程序吧�?写篏�?-(

五、小�l?/b>

　　敬请��x��《COM �l��g设计与应�?�?�?-----如何增加 ATL �l��g中的�W�二个接�?
�?�Q�编译代�?存根�Q�vc6.0 中稍微麻烦，我们在后面介�l�“进�E�外�l��g”和“远�E�组件”的时候再介绍。在 vc.net 2003 下则比较��单，因�ؓ代理/存根作�ؓ单独的一个工�E�项目会自动加到我们的解��x��案中了�?img src ="http://m.shnenglu.com/yishanhante/aggbug/19617.html" width = "1" height = "1" />

jay 2007-03-12 11:01 发表评论

jay — Mon, 12 Mar 2007 02:40:00 GMT
一、前�a�

　　1、与《COM �l��g设计与应�?�?�?/font>的内容基本一致。但本回讲解的是�?vc.net 2003 下的使用�Ҏ��Q�即使你不再使用vc6.0�Q�也请和上一回的内容�Q�参照比寏V�?br />　　2、这�W�一个组�Ӟ��除了所�?COM �l��g必须�?IUnknown 接口外，我们再实��C��个自己定义的接口 IFun�Q�它有两个函敎ͼ� Add()完成两个数值的加法�Q�Cat()完成两个字符串的�q�接�?br />　　3、下�?.....好好听讲! 开始了:-)
　
二�?/b>建立 ATL 工程

　　步骤2.1�Q�徏立一个解��x��案�?br />　　步骤2.2�Q�在该解��x��案中�Q�新��Z��?vc++ �?ATL ��目。示例程序叫 Simple2�Q��ƈ选择DLL方式�Q�见图一、图二�?br />

图一、新�?ATL ��目

图二、选择非属性化的DLL�l��g�c�d��

　　属性化 属性化�~�程�Q�是未来的方向，但我们现在先不要选它�?br />　　动态链接库(DLL) 选择它�?br />　　可执行文�?EXE) 以后再讲�?br />　　服务(EXE) 表示建立一个系�l�服务组件程序，�pȝ��启动后就会加载�ƈ执行的程序�?br />　　允许合�ƈ代理/存根(stub)代码 选择该项表示把“代�?存根”代码合�q�到�l��g�E�序中，否则需要单独编译，单独注册代理存根�E�序。代�?存根�Q�这个是什么概念？�q�记得我们在上回�?/font>中介�l�的吗？当调用者调用进�E�外或远�E�组件功能的时候，其实是代�?存根负责数据交换的。关于代�?存根的具体变成和操作�Q�以后再说啦......
　　支持 MFC 除非有特�D�的原因�Q�我们写 ATL �E�序�Q�最好不要选择该项。你可能会说�Q�如果没有MFC的支持，那CString怎么办呀�Q�告诉你个秘密吧�Q�一般�h我都不告诉他�Q�我后半辈子��靠着�q�个�U�密�zȝ��了：
　　1、你会STL吗？可以�?STL 中的 string 代替�Q?br />　　2、自己写�?MyString �c�，嘿嘿�Q?br />　　3、悄悄地、秘密地、不要告诉别人（特别是别告诉微��Y�Q�，�?MFC 中的 CString 源码拿过来用�Q?br />　　4、��?CComBSTR �c�，臛_��也能��化我们字�W�串操作�Q?br />　　5、直接用 API 操作字符�Ԍ��反正我们大家学习 C 语言的时候，都是从这里干��L��。（�{�于没说�Q�呵呵）
　　支持 COM+ 1.0 支持事务处理�?COM+ 功能。COM+ 也许在第 99 回介�l�吧�?br />

三、添�?ATL 对象�c?/b>

　　步骤3.1�Q�菜�?��目\��d��c?.."�Q�或者用鼠标右键�?��目中弹��?��d��\��d��c?.."�Q��ƈ选择 ATL ��单对象。见图三�?br />

图三、选择建立ATL��单对�?br />
　　除了��单对�?只实��C�� IUnknown 接口)�Q�还可以选择“ATL控�g�?ActiveX�Q�实��C��10多个接口)......可以选择的组件对象类型很多，但本质上�Q�就是让向导帮我们默认加上一些接口。在以后的文章中�Q�陆�l�介�l�吧�?br />
　　步骤3.2�Q�增加自定义�c?CFun(接口 IFun) ,见图四�?br />

囑֛�、填写名�U?br />
　　其实�Q�我们只需要输入简�U�ͼ�其它的项目会自动填写。没什么多说的�Q�只请大家注意一�?ProgID ��，默认�?ProgID 构造方式�ؓ“项目名.��U�名”�?br />
　　步骤3.3�Q�填写接口属性选项�Q�见�?五�?br />

图五、接口选项

　　�U�程模型 COM 中的�U�程�Q�我认�ؓ是最讨厌�Q�最复杂的部分。COM �U�程和公寓的概念�Q�留待后�l�介�l�。现在吗......大家都�?单元"(Apartment)�Q�它代表什么那�Q�简单地��_��当在�U�程中调用组件函数的时候，�q�些调用会排队进行。因此，�q�种模式下，我们可以暂时不用考虑同步的问题�?�?)
　　接口。双�?Dual)�Q�这个非�?非常重要�Q�非帔R��常常用，但我们今天不�?�?)�?b>切记�Q�切讎ͼ�我们的这�W�一�?COM �E�序中，一定要选择“自定义”！�Q�！�Q?/b>�Q�如果你选错了，请删除全部内容，重新来过。）
　　聚合我们写的�l��g�Q�将来是否允许被别�h聚合(�?)使用。“只能创��Zؓ聚合”，有点�c�M�� C++ 中的�U�虚�c�，你要是��d��E�师�Q�只负责设计但不亲自写代码的话，才选择它�?br />　　ISupportErrorInfo 是否支持丰富信息的错误处理接口。以后就讌Ӏ?br />　　�q�接�?/b> 是否支持�q�接�Ҏ��口（事�g、回调）。以后就讌Ӏ?br />　　IObjectWithSite 是否支持IE的调�?br />

四、添加接口函�?br />

囑օ�、调出增加接口方法的菜单

图七、增加接口函�?Add

　　��h��照图�C�的�Ҏ��Q�增加Add()函数�Q�增加Cat()函数。[in]表示参数方向是输入；[out]表示参数方向是输出；[out,retval]表示参数方向是输出，同时可以作�ؓ函数�q�算�l�果的返回倹{��一个函��C��Q�可以有多个[in]、[out]�Q�但[retval]只能有一个，�q�且要和[out]�l�合后在最后一个位�|��?�?)

囑օ�、接口函数定义完成后的图�C?br />
　　我们都知道，要想改变 C++ 中的�c�d��敎ͼ�需要修改两个地方：一是头文�g(.h)中类的函数声明，二是函数�?.cpp)文�g的实现处。而我们现在用 ATL 写组件程序，则还要修改一个地方，��是接口定义(IDL)文�g。别着�?IDL 下次��p��讨论啦�?br />

五、实现接口函�?/b>

　　鼠标双点囑օ�中CFun\基项和接口\Add(...)��可以开始输入函数实��C��Q?/p>
STDMETHODIMP CFun::Add(long n1, long n2, long *pVal) { *pVal = n1 + n2; return S_OK; }
�q�个太简单了�Q�不再浪费“口条”。下面我们实现字�W�串�q�接的Cat()函数�Q?pre>STDMETHODIMP CFun::Cat(BSTR s1, BSTR s2, BSTR *pVal) { int nLen1 = ::SysStringLen( s1 ); // s1 的字�W�长�? int nLen2 = ::SysStringLen( s2 ); // s2 的字�W�长�? *pVal = ::SysAllocStringLen( s1, nLen1 + nLen2 );// 构造新�?BSTR 同时�?s1 先保存进�? if( nLen2 ) { ::memcpy( *pVal + nLen1, s2, nLen2 * sizeof(WCHAR) ); // 然后�?s2 再连接进�? // wcscat( *pVal, s2 ); } return S_OK; }学生�Q�上面的函数实现�Q�完全是调用基本�?API 方式完成的�?br />老师�Q�是的，说实话，的确比较烦琐�?br />学生�Q�我们是用memcpy()完成�q�接�W�二个字�W�串功能的，那么��Z��么不用函�?wcscat()那？
老师�Q�多数情况下可以�Q�但你需要知道：�׃��BSTR包含有字�W�串长度�Q�因此实际的BSTR字符串内容中是可以存储L''\0''的，而函�?wcscat() 是以L''\0''作�ؓ复制�l�束标志�Q�因此可能会丢失数据。明白了吗？
学生�Q�明白，明白。我看过《COM �l��g设计与应�?�?之数据类型�?/font>后就明白了。那么老师�Q�有没有��单一些的�Ҏ��那？
老师�Q�有呀�Q�你�?.....
STDMETHODIMP CFun::Cat(BSTR s1, BSTR s2, BSTR *pVal) { CComBSTR sResult( s1 ); sResult.AppendBSTR( s2 ); *pVal = sResult.Copy(); // *pVal = sResult.Detach(); return S_OK; }
学生�Q�哈哈，好！使用�?CComBSTR�Q�这个就��单多了。CComBSTR::Copy()和CComBSTR::Detach()有什么区别？
老师�Q�CComBSTR::Copy() 会制造一�?BSTR 的副本，另外CComBSTR::CopyTo()也有�c�M��功能。而CComBSTR::Detach()是��对象与内部的 BSTR 指针剥离�Q�这个函数由于没有复制过�E�，因此速度�E�微快一点点。但要注意，一但剥��d��Q�就不能再��用该对象啦�?br />学生�Q�老师�Q�您讲的太牛啦，我对您的敬�Ԓ如巍巍泰山，直入云霄......
老师�Q�STOP�Q�STOP�Q�留作业�?.....
　　1、自己先按照今天讲的内容写出�q�个�l��g�Q?br />　　2、不��你懂不懂，一定要去观�?IDL 文�g�Q�CPP 文�g�Q?br />　　3、编译后�Q�看都��生了些什么文�Ӟ��如果是文本的文�g�Q�就打开看看�Q?br />　　4、下载本文的�C�Z��E�序(vc.net 2003版本)�~�译�q�行�Q�看看效果。然后预习一下示例程序中的调用方法；
学生�Q�知道啦�Q�快下课吧，我要上厕所�Q�我都憋的不行了......
老师�Q�下课！别忘了顶我的帖子呀......

六、小�l?/b>

　　本回介绍�W�一个ATL�l��g�E�序的徏立步骤，而如何��用该�l��g�Q�敬请关注《COM �l��g设计与应�?�?》�?
�?�Q�Apartment�Q�系�l�通过隐藏的窗口消息来排队�l��g调用�Q�因此我们可以暂时不考虑同步问题。注意，是暂时哈�?br />�?�Q�双接口表示在一个接口中�Q�同时支持自定义接口�?IDispatch 接口。以后，以后�Q�以后就讌Ӏ�因为双接口非常重要�Q�我们以后会天天讌Ӏ�夜夜讲、常常讲------��U�“三讜y�?)
�?�Q�组件的重用�Ҏ��?个，聚合和包宏V�?br />�?�Q�这些都�?IDL 文�g中的概念�Q�以后用��C��么，��׃��l�什么�?img src ="http://m.shnenglu.com/yishanhante/aggbug/19606.html" width = "1" height = "1" />

jay 2007-03-12 10:40 发表评论

jay — Mon, 12 Mar 2007 02:39:00 GMT
一、前�a�

　　1、如果你在��?vc5.0 及以前的版本�Q�请你升�U��ؓ vc6.0 �?vc.net 2003�Q?br />　　2、如果你在��?vc6.0 (ATL 3.0)请阅��L��回内容；
　　3、如果你在��?vc.net(ATL 7.0)请阅��M��回内容；(当然读读本文内容也不�?
　　4、这�W�一个组�Ӟ��除了所�?COM �l��g必须�?IUnknown 接口外，我们再实��C��个自己定义的接口 IFun�Q�它有两个函敎ͼ� Add()完成两个数值的加法�Q�Cat()完成两个字符串的�q�接�?br />　　5、下�?.....好好听讲! 开始了:-)

二�?/b>建立 ATL 工程
　　步骤2.1�Q�徏立一个工作区(WorkSpace)�?br />　　步骤2.2�Q�在工作��Z��Q�徏立一�?ATL 工程(Project)。示例程序叫 Simple1�Q��ƈ选择DLL方式�Q�见图一�?br />

图一、徏�?ATL DLL 工程

　　Dynamic Link Library(DLL) 表示建立一�?DLL 的组件程序�?br />　　Executable(EXE) 表示建立一�?EXE 的组件程序�?br />　　Service(EXE) 表示建立一个服务程序，�pȝ��启动后就会加载�ƈ执行的程序�?br />　　Allow merging of proxy/stub code 选择该项表示把“代�?存根”代码合�q�到�l��g�E�序中，否则需要单独编译，单独注册代理存根�E�序。代�?存根�Q�这个是什么概念？�q�记得我们在上回�?/a>中介�l�的吗？当调用者调用进�E�外或远�E�组件功能的时候，其实是代�?存根负责数据交换的。关于代�?存根的具体变成和操作�Q�以后再说啦......
　　Support MFC 除非有特�D�的原因�Q�我们写 ATL �E�序�Q�最好不要选择该项。你可能会说�Q�如果没有MFC的支持，那CString怎么办呀�Q�告诉你个秘密吧�Q�一般�h我都不告诉他�Q�我后半辈子��靠着�q�个�U�密�zȝ��了：
　　1、你会STL吗？可以�?STL 中的 string 代替�Q?br />　　2、自己写�?MyString �c�，嘿嘿�Q?br />　　3、悄悄地、秘密地、不要告诉别人（特别是别告诉微��Y�Q�，�?MFC 中的 CString 源码拿过来用�Q?br />　　4、��?CComBSTR �c�，臛_��也能��化我们字�W�串操作�Q?br />　　5、直接用 API 操作字符�Ԍ��反正我们大家学习 C 语言的时候，都是从这里干��L��。（�{�于没说�Q�呵呵）
　　Support MTS 支持事务处理�Q�也��是是否支持 COM+ 功能。COM+ 也许在第 99 回介�l�吧�?br />

三、增�?ATL 对象�c?br />
　　步骤3.1�Q�菜�?Insert\New ATL Object...�Q�或者用鼠标右键�?ClassView 卡片中弹��单）�q��择Object 分类�Q�选中 Simple Object ��目。见图二�?br />

图二、选择建立��单COM对象

　　Category Object 普通组件。其中可以选择的组件对象类型很多，但本质上�Q�就是让向导帮我们默认加上一些接口。比如我们�?"Simple Object"�Q�则向导�l�我们的�l��g加上 IUnknown 接口�Q�我们�?"Internet Explorer Object"�Q�则向导除了加上 IUnknown 接口外，再增加一个给 IE 所使用�?IObjectWithSite 接口。当然了�Q�我们完全可以手工增加�Q何接口�?br />　　Category Controls ActiveX 控�g。其中可以选择�?ActiveX �c�d��也很多。我们在后箋的专门介�l?ActiveX �~�程中再讨论�?br />　　Category Miscellaneous 辅助杂类�l��g�?br />　　Categroy Data Access 数据库类�l��g(我最讨厌数据库编�E�了�Q�所以我也不�?�?br />
　　步骤3.2�Q�增加自定义�c?CFun(接口 IFun) ,见图三�?br />

图三、输入类中的各项名称
　　其实�Q�我们只需要输入短�?Short Name)�Q�其它的��目会自动填写。没什么多说的�Q�只请大家注意一�?ProgID ��，默认�?ProgID 构造方式�ؓ“工�E�名.短名”�?br />
　　步骤3.3�Q�填写接口属性，见图四�?br />
囑֛�、接口属�?br />
　　Threading Model 选择�l��g支持的线�E�模型。COM 中的�U�程�Q�我认�ؓ是最讨厌�Q�最复杂的部分。COM �U�程和公寓的概念�Q�留待后�l�介�l�。现在吗......大家都�?Apartment�Q�它代表什么那�Q�简单地��_��当在�U�程中调用组件函数的时候，�q�些调用会排队进行。因此，�q�种模式下，我们可以暂时不用考虑同步的问题�?�?)
　　 Interface 接口基本�c�d��。Dual 表示支持双接�?�?)�Q�这个非�?非常重要�Q�非帔R��常常用，但我们今天不讌Ӏ�Custom 表示自定义借口�?b>切记�Q�切讎ͼ�我们的这�W�一�?COM �E�序中，一定要选择它！�Q�！�Q?/b>�Q�如果你选错了，请删除全部内容，重新来过。）
　　 Aggregation 我们写的�l��g�Q�将来是否允许被别�h聚合(�?)使用。Only 表示必须被聚合才能��用，有点�c�M�� C++ 中的�U�虚�c�，你要是��d��E�师�Q�只负责设计但不亲自写代码的话，才选择它�?br />　　Support ISupportErrorInfo 是否支持丰富信息的错误处理接口。以后就讌Ӏ?br />　　Support Connection Points 是否支持�q�接�Ҏ��口（事�g、回调）。以后就讌Ӏ?br />　　Free Threaded Marshaler 以后也不�Ԍ��q��打死你，我也不说�Q?�?)

四、添加接口函�?br />

图五、调出增加接口方法的菜单

囑օ�、增加接口函�?Add

图七、增加接口函�?Cat

　　请严格按照图六的方式�Q�增加Add()函数�Q�由于图七中增加Cat()函数的参数比较长�Q�我没有适当的输入空��|��请大家自��p��入的时候注意一下。[in]表示参数方向是输入；[out]表示参数方向是输出；[out,retval]表示参数方向是输出，同时可以作�ؓ函数�q�算�l�果的返回倹{��一个函��C��Q�可以有多个[in]、[out]�Q�但[retval]只能有一个，�q�且要和[out]�l�合后在最后一个位�|��?�?)

囑օ�、接口函数定义完成后的图�C?br />　　我们都知道，要想改变 C++ 中的�c�d��敎ͼ�需要修改两个地方：一是头文�g(.h)中类的函数声明，二是函数�?.cpp)文�g的实现处。而我们现在用 ATL 写组件程序，则还要修改一个地方，��是接口定义(IDL)文�g。别着�?IDL 下次��p��讨论啦�?br />　　�׃�� vc6.0 的BUG�Q�导致大家在增加完接口和接口函数后，可能不会向上图（囑օ��Q�所表现的样式。解��x��法：
　
1 关闭工程�Q�然后重新打开该方法常常有�?/td>
2 关闭 IDE�Q�然后重新运�?/td> 　
3 打开 IDL 文�g�Q�检查接口函数是否正��，如不正确请修�?/td> 　
4 打开 IDL 文�g�Q�随便修改一�?加一个空��|��再删除这个空�?�Q�然后保�?/td> 该方法常常有�?/td>
5 打开 h/cpp 文�g�Q�检查函数是否存在或是否正确�Q�有则改�?/td> 无则嘉勉�Q�不说完�q�个成语心理别扭
6 删除 IDL/H/CPP 中的接口函数�Q�然�?/td> 再来一�?/td>
7 重新建立工程、重新安装vc、重新安装windows、砸计算�?/td> 砸！

五、实现接口函�?/b>

　　鼠标双点囑օ�中CFun\IFun\Add(...)��可以开始输入函数实��C��Q?/p>
STDMETHODIMP CFun::Add(long n1, long n2, long *pVal) { *pVal = n1 + n2; return S_OK; }
�q�个太简单了�Q�不再浪费“口条”。下面我们实现字�W�串�q�接的Cat()函数�Q?pre>STDMETHODIMP CFun::Cat(BSTR s1, BSTR s2, BSTR *pVal) { int nLen1 = ::SysStringLen( s1 ); // s1 的字�W�长�? int nLen2 = ::SysStringLen( s2 ); // s2 的字�W�长�? *pVal = ::SysAllocStringLen( s1, nLen1 + nLen2 ); // 构造新�?BSTR 同时�?s1 先保存进�? if( nLen2 ) { ::memcpy( *pVal + nLen1, s2, nLen2 * sizeof(WCHAR) ); // 然后�?s2 再连接进�? // wcscat( *pVal, s2 ); } return S_OK; }学生�Q�上面的函数实现�Q�完全是调用基本�?API 方式完成的�?br />老师�Q�是的，说实话，的确比较烦琐�?br />学生�Q�我们是用memcpy()完成�q�接�W�二个字�W�串功能的，那么��Z��么不用函�?wcscat()那？
老师�Q�多数情况下可以�Q�但你需要知道：�׃��BSTR包含有字�W�串长度�Q�因此实际的BSTR字符串内容中是可以存储L''\0''的，而函�?wcscat() 是以L''\0''作�ؓ复制�l�束标志�Q�因此可能会丢失数据。明白了吗？
学生�Q�明白，明白。我看过�?a >COM �l��g设计与应�?�?之数据类型》后��明白了。那么老师�Q�有没有��单一些的�Ҏ��那？
老师�Q�有呀�Q�你�?.....
STDMETHODIMP CFun::Cat(BSTR s1, BSTR s2, BSTR *pVal) { CComBSTR sResult( s1 ); sResult.AppendBSTR( s2 ); *pVal = sResult.Copy(); // *pVal = sResult.Detach(); return S_OK; }
学生�Q�哈哈，好！使用�?CComBSTR�Q�这个就��单多了。CComBSTR::Copy()和CComBSTR::Detach()有什么区别？
老师�Q�CComBSTR::Copy() 会制造一�?BSTR 的副本，另外CComBSTR::CopyTo()也有�c�M��功能。而CComBSTR::Detach()是��对象与内部的 BSTR 指针剥离�Q�这个函数由于没有复制过�E�，因此速度�E�微快一点点。但要注意，一但剥��d��Q�就不能再��用该对象啦�?br />学生�Q�老师�Q�您讲的太牛啦，我对您的敬�Ԓ如巍巍泰山，直入云霄......
老师�Q�STOP�Q�STOP�Q�留作业�?.....
　　 1、自己先按照今天讲的内容写出�q�个�l��g�Q?br />　　 2、不��你懂不懂，一定要去观�?IDL 文�g�Q�CPP 文�g�Q?br />　　 3、编译后�Q�看都��生了些什么文�Ӟ��如果是文本的文�g�Q�就打开看看�Q?br />　　 4、下载本文的�C�Z��E�序(vc6.0版本)�~�译�q�行�Q�看看效果。然后预习一下示例程序中的调用方法；
学生�Q�知道啦�Q�快下课吧，我要上厕所�Q�我都憋的不行了......
老师�Q�下课！别忘了顶我的帖子呀......

六、小�l?/b>

　　本回介绍�W�一个ATL�l��g�E�序的徏立步骤，而如何��用该�l��g�Q�敬请关注《COM �l��g设计与应�?�?》�?br />　
�?�Q�Apartment�Q�系�l�通过隐藏的窗口消息来排队�l��g调用�Q�因此我们可以暂时不考虑同步问题。注意，是暂时哈�?br />�?�Q�双接口表示在一个接口中�Q�同时支持自定义接口�?IDispatch 接口。以后，以后�Q�以后就讌Ӏ�因为双接口非常重要�Q�我们以后会天天讌Ӏ�夜夜讲、常常讲------��U�“三讜y�?)
�?�Q�组件的重用�Ҏ��?个，聚合和包宏V�?br />�?�Q�名�U�的功能很好听，但微软根本就没有实现�?br />�?�Q�这些都�?IDL 文�g中的概念�Q�以后用��C��么，��׃��l�什么�?br />

jay 2007-03-12 10:39 发表评论

jay — Mon, 12 Mar 2007 02:01:00 GMT

本文假设你熟悉C++和COM�?br />
摘要�Q?/b>
    ATL——活动模板库�Q�The Active Template Library�Q�，其设计旨在让��Z��用C++方便灉|��地开发COM对象。ATL本��n相当��y灉|��Q�这是它最大的优点。用它可以创��量��的，自包含的�Q�可复用的二�q�制代码�Q�不用�Q何附加的�q�行时DLLs支持�?br />    �׃��COM技术良好的口碑�Q�越来越多的�E�序员已�l�走�q�或正在走进COM的编�E�世界。它��像盛夏里的冰镇啤酒�Q�从来不会让你失望。可惜作��Z��个C++�E�序员来��_��C++从不与我分��nCOM的极致以及我对COM的情有独钟�?
    C++与COM之间若即若离�Q�和�q�_��处，一�ơ又一�ơ在每个对象中用同样��z�的几行代码实现IUnknown。我敢肯定将来C++�~�译器和链接器会实现C++对象和COM对象之间自然的无意识的对应和映射�Q�目前这个环境只存在于实验室中，因此它肯定不是一个你我今天可以购买的产品。眼下可得到的最接近�q�个环境的东西就是活动模板库——ATL�?br />
��Z��么��用ATL?
    ATL是在单层�Q�single-tier�Q�应用逐渐�q�时�Q�分布式应用逐渐成�ؓ��L��q�样一个环境中诞生的，它最初的版本是在四个C++头文件中�Q�其中有一个还是空的。它所形成的出色的构架专门用于开发现代分布式应用所需的轻量��COM�l��g。作��Z��个模块化的标准组�Ӟ��ATL不像MFC有厚重的基础�l�构�Q�省时好用的库��得成百上千的�E�序员一�ơ又一�ơ轻村֮�现IUnknown 和IClassFactory�?br />    ATL的构架�ƈ不打��包�|�万象，无所不能。其�W�一个版本对实现IUnknown�Q�IClassFactory�Q�IDispatch�Q�IconnectionPointContainer及COM枚�D提供非常 ��C��的支持。第二个版本除了可以�~�写ActiveX控�g外，�q�对最初的�W�一个版本中ATL�c�进行了增强。ATL不提供集合（collections�Q�和�Ԍ��strings�Q�的处理 �Q�它假设你用标准的C++库进行这些处理；不支持ODBC——这个世界正在�{�U�d��Z��COM的不需要包装的数据存取方式�Q�不支持WinSock打包�c?-sockets本��n也是新的东西�Q�ATL也不支持完整的Win32 API打包�c�Z��—ATL2.0的实现机制提供了对话框和WndProcs支持。此外ATL中没有MFC中的文档/视图模型。取而代之的是ATL那更具�׾~�性和灉|�� 性的通过COM接口�Q�如ActiveX控�g�Q�与��Z��UI的对象之间的沟通模式�?br />    使用正确的工具非常关键。如果你正在�~�写一个不可见的COM�l��g�Q�那么ATL与MFC比�v来，从开发效率，可�׾~�性，�q�行时性能以及可执行文件大��各斚w��来看�Q�ATL可能都是最好的选择。对于现代基于ActiveX控�g的用��L��面，ATL所产生的代码也比MFC更小更快。另一斚w��Q�与MFC的类向导相比�Q�ATL需要更多的COM知识。ATL与STL一��P��对于单层应用没什么帮助，而MFC在这斚w��保持着它的优势�?br />    ATL的设计在很大�E�度上来自STL的灵感，STL与所有ANSI/ISO兼容的C++�~�译器一起已�l�被�U�_��成�ؓ标准C++库的一部分。像STL一��P��ATL大胆使用C++模板。模板是C++中众多具有争议的�Ҏ��之一。每每��用不当都会导致执行�؜乱，降低性能和难以理解的代码。明智地使用模板所产生的通用性效果和�c�d��安全�Ҏ��则是其它方法所望尘莫及的。ATL与STL一样陷入了两个极端。幸�q�的�?在L大胆使用C++模板的同�Ӟ��~�译器和链接器技术也在以同样的步伐向前发展。�ؓ当前和将来的开发进行STL和ATL的合理选择�?br />    ��管模板在内部得到广泛的使用�Q�但是在用ATL技术时�Q�你不用��L��入或兛_��那些模板中的��括弧。因为ATL本��n带有ATL对象向导�Q�参见图一�Q�：

图一 ATL 对象向导

    对象向导产生大量��Z��ATL模板�cȝ��省的对象实现代码�Q�即框架代码�Q�。这些缺省的对象�c�d��?a >附表一所列。ATL对象向导允许��M��?快速徏立COM对象�q�且在分分钟之内让它�q�行��h��Q�不用去考虑COM或ATL的细节问题。当�Ӟ��Z��能充分驾驭ATL�Q�你必须掌握C++�Q�模板和COM�~�程技术。对于大型的对象�c�，只要在ATL对象向导所产生的缺省实玎ͼ�框架代码�Q�中加入�Ҏ��实现来输出定制接口，�q�也是大多数开发�h员开始实现COM对象时的重点所在�?br />    初次接触ATL�Ӟ��其体�pȝ��构给人的感觉是神�U�和不可思议�?xxxxime xime="7">HelloATL是一个最��单的��Z��ATL的进�E�内服务器源代码以及用SDK�Q�纯�_�用C++�~�写�Q�实现的同样一个进�E�内服务器源代码。在真正构徏��Z��个COM�l��g之前�Q�代码需要经�q�反反复复多�ơ斟酌和修改。对于想加速开发COM�l��g速度的主��组件开发�h员来��_��ATL体系�l�构�q�不是什么大问题�Q�因为对象向��g�生了所需要的全部框架代码�Q�只要你加入�Ҏ��定义卛_��。对于认真的COM开发�h员和�pȝ��~�程人员来说�Q�ATL提供了一个用C++建立COM�l��g的高�U�的�Q�可扩展的体�pȝ��构。一旦你理解和掌握了�q�个体系�l�构�q�能��N��对象向导�Q�你��׃��看到ATL的表现能力和强大的功�?�Q�它完全可以和原始的COM�~�程技术媲��?br />    另外一个��用ATL开发COM�l��g的理由是Visual C++ 5.0+集成开发环境（IDE�Q�对ATL的高度支持�?微��Y在Visual C++ 5.0+中将ATL所要用到的接口定义语言�Q�IDL�Q�集成到了C++�~�辑器中。（待箋�Q?br />

jay 2007-03-12 10:01 发表评论

#include �Ҏ��	IDL�~�译后，为方便C/C++�E�序员的使用�Q�会产生xxx.h和xxx_i.c文�g。我们真�q�福�Q�直�?include后就可以使用�?/td>
#import �Ҏ��	比较通用的方法，vc 会帮我们产生包装�c�，让我们的调用更方�?/td>
加蝲�c�d��库包装类 �Ҏ��	如果�l��g提供�?IDispatch 接口�Q�用�q�个�Ҏ��调用�l��g是最��单的啦。不�q�还没讲IDispatch�Q�只能看以后的文章啦
加蝲ActiveX包装�c?�Ҏ��	ActiveX �q�没介绍呢，以后再说�?/td>

�C�Z��	�Ҏ��	��要说�?/b>
1	#include	完全用最基本�?API 方式调用�l��g�Q��大家熟悉调用原理
2	#include	大部分��?API 方式�Q��?CComBSTR ��化对字符串的使用
3	#include	展示��指针 CComPtr<> 的��用方�?/td>
4	#include	展示��指针 CComPtr<> �?CComQIPtr<> 混合的��用方�?/td>
5	#include	展示��指针 CComQIPtr<> 的��用方�?/td>
6	#include	展示��指针的释放方�?/td>
7	#import	vc 包装的智能指�?IxxxPtr、_bstr_t、_variant_t 的��用方法和异常处理
8	#import	import 后的命名�I�间的��用方�?/td>

1	关闭工程�Q�然后重新打开	该方法常常有�?/td>
2	关闭 IDE�Q�然后重新运�?/td>
3	打开 IDL 文�g�Q�检查接口函数是否正��，如不正确请修�?/td>
4	打开 IDL 文�g�Q�随便修改一�?加一个空��\|��再删除这个空�?�Q�然后保�?/td>	该方法常常有�?/td>
5	打开 h/cpp 文�g�Q�检查函数是否存在或是否正确�Q�有则改�?/td>	无则嘉勉�Q�不说完�q�个成语心理别扭
6	删除 IDL/H/CPP 中的接口函数�Q�然�?/td>	再来一�?/td>
7	重新建立工程、重新安装vc、重新安装windows、砸计算�?/td>	砸！