久久久久国产精品嫩草影院,91久久精一区二区三区大全,2021国内精品久久久久久影院

�?+ — Sun, 03 Feb 2008 18:53:00 GMT

WinAPI�~�程基础 �?消息分流器[z]

文章作者：Bideyore[E.S.T]
信息来源�Q�邪恶八�q�制中国�Q?a target="_blank">www.EvilOctal.com�Q?br>

对于熟悉Win API�~�程的同志们来说�Q�windowsx.h�q�个头文件应该不会太陌生吧，�q�次要讲的内容就来自�q�个windowsx.h头文件�?br>
�l�常能在msdn上查到这样一些函敎ͼ�明明是个函数�Q�而且模样长得和一般的api函数也一样一��L��Q�可却叫做macro�Q��ؓ什么呢�Q�留意一下函��C��用的requirement�Q�你会发玎ͼ�它的声明正是在windowsx.h�q�个头文仉��?br>
Windowsx.h包含了这样一些内容：
宏API�Q�窗口消息分��器�Q�控件API�Q?br style="color: #ff0000;">
所有的�q�些宏定义，可以使你的程序更加安全，��z�，�l�构更清晎ͼ�大大提高�E�序的可��L��；其中�H�口消息分流器（message cracker�Q�是我们今天要讨论的话题�Q�它可以使我们的API�E�序变得更简�z�。下面就�q�入我们的主题：�Q�有关windowsx.h的更多内容，可以参�? MS Knowledge Base Article #83456.�Q?br>
消息分流器是Windows提供的一�l�宏定义�Q�它的两个最大的作用�Q�用MS的话来说�Q�就是：

�?安全的数据类型，因�ؓ消息分流器完成了大量的类型�{换的工作�Q?br>�?使程序向32位windows的�{化更��单；

当然�Q��用消息分��器会大大改变程序的面貌�Q�你也可以选择不��用它�?br>
下面我们��׃��一个对话框�H�口的消息处理过�E��ؓ例，看看消息分流器到底是怎么�q�作的�?br>

1�Q�消息分��器的基本��?br>先看一个普通的�H�口消息处理函数�Q�它可能需要处理一些窗口的初始化，无效客户区重�l�等消息�Q?br>
LRESULT CALLBACK WndProc (HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_CREATE:
// ...
return 0;

case WM_PAINT:
// ...
return 0;

case WM_DESTROY:
//...
return 0;
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}

而通过使用消息分流器，我们可以把每个case都写到相应的消息处理函数中，��像下面�q�样�Q?br>
LRESULT CALLBACK WndProc (HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_CREATE:
return HANDLE_WM_CREATE(hwnd, wParam, lParam, Cls_OnCreate);

case WM_PAINT:
return HANDLE_WM_PAINT(hwnd, wParam, lParam, Cls_OnPaint);

case WM_DESTROY:
return HANDLE_WM_DESTROY(hwnd, wParam, lParam, Cls_OnDestroy);
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}

�q�里用到了三个宏定义�Q�HANDLE_WM_CREATE, HANDLE_WM_PAINT, HANDLE_WM_DESTROY�Q�这三个宏定义就是我们的三个消息分流器（别看叫什么分��器�Q�说�I�了也不值几个钱�Q�呵呵）�Q�它们在windowsx.h中的定义如下�Q?br>
#define HANDLE_WM_CREATE(hwnd, wParam, lParam, fn)
((fn)((hwnd), (LPCREATESTRUCT)(lParam)) ? 0L : (LRESULT)-1L)
#define HANDLE_WM_PAINT(hwnd, wParam, lParam, fn)
((fn)(hwnd), 0L)
#define HANDLE_WM_DESTROYCLIPBOARD(hwnd, wParam, lParam, fn)
((fn)(hwnd), 0L)

把这三个宏定义替换回去，��变成：

LRESULT CALLBACK WndProc (HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_CREATE:
return Cls_OnCreate(hwnd, (LPCREATESTRUCT)(lParam) ? 0L : (LRESULT)-1L;
// 如果处理了消息，则Cls_OnCreate应返回TRUE�Q�导致WndProc�q�回0�Q�否则Cls_OnCreate�q�回FALSE�Q�导致WndProc�q�回-1�Q?br> case WM_PAINT:
return Cls_OnPaint(hwnd), 0L;
// 逗号表达式；Cls_OnPaint是void�c�d��Q�这里返�?�Q?
case WM_DESTROY:
return Cls_OnDestroy(hwnd), 0L; // 同Cls_OnPaint
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}

之后我们��可以按照消息分��器的定义编写相应的消息处理函数了：

BOOL Cls_OnCreate(HWND hwnd, LPCREATESTRUCT lpCreateStruct){…};
void Cls_OnPaint(HWND hwnd){…};
void Cls_OnDestroyClipboard(HWND hwnd){…};

windowsx.h�q�提供了一个更加简化的�Ҏ��Q��用HANDLE_MSG宏，�q�个宏是�q�样定义的：

#define HANDLE_MSG(hwnd, message, fn)
case (message): return HANDLE_##message((hwnd), (wParam), (lParam), (fn))

�q�个宏要做的��是�Ҏ��不同的message�Q?#用来�q�接前后的字�W�串�Q�，把自�?#8220;变成”相应的HANDLE_XXXXMESSAGE形式的宏�Q�再通过相应的宏来执行消息处理代码；
比如实际代码中写入：

HANDLE_MSG(hwnd, WM_CREATE, Cls_OnCreate)

则经�q��{换就变成�Q?br>
case (WM_CREATE): return HANDLE_WM_CREATE((hwnd), (wParam), (lParam), (Cls_OnCreate))

�q�样�Q�我们就可以直接把程序写为：
LRESULT CALLBACK WndProc (HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
HANDLE_MSG(hwnd, WM_CREATE, Cls_OnCreate);
HANDLE_MSG(hwnd, WM_PAINT, Cls_OnPaint);
HANDLE_MSG(hwnd, WM_DESTROY, Cls_OnDestroy);
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}

�? 后直接编写相应的消息处理�q�程��可以了。是不是��z�多了？而且把消息处理封装到函数里面�Q�就可以使用VS直接跌��{到这个函敎ͼ�再也不用费劲��L��那个 case了。要注意的一�Ҏ��Q�虽然windowsx.h里包括了所有消息对应的分流器，但它们的参数是宏定义昑ּ�说明的，在编写消息处理函数时�Q�必��遵�? 宏定义中的参数类型，否则会导致错误；�q�么多消息分��器�Q�我们每�ơ新写一个消息处理函数时��得看看是否把参数设�|�正��了�Q�整个过�E�繁琐冗�ѝ��好在已�l�有一个工具叫Message Cracker Wizard�Q�可以帮助我们生成消息分��器和相关的处理�q�程�Q�具体见�Q?a target="_blank">http://www.codeproject.com/win32/msgcrackwizard.asp�?br>

2�Q�在对话框中使用消息分流�?br>在对话框消息处理中，�H�口子类化是我们�l�常使用的手�D�，�q�也可以通过消息分流器实玎ͼ�但是有点��问�?:>
下面是一个��用了windowsx.h消息分流器的对话框及其处理过�E�：
……
int WINAPI _tWinMain(HINSTANCE hinstExe, HINSTANCE, PTSTR pszCmdLine, int)
{
DialogBoxParam(
hinstExe, MAKEINTRESOURCE(IDD_PASSTHRU), NULL, (DLGPROC)Dlg_Proc, 0);

return(0);
}
……

LRESULT CALLBACK Dlg_Proc (HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
HANDLE_MSG(hwnd, WM_INITDIALOG, Cls_OnInitDialog); // 不能直接使用HANDLE_MSG�?br>HANDLE_MSG(hwnd, WM_COMMAND, Cls_OnCommand); // 不能直接使用HANDLE_MSG�?br>}

return false;
}

以上�E�序中直接��用HANDLE_MSG可能��D��错误�Q��ؓ什么呢�Q�问题出在子�c�d��的消息处理过�E�的�q�回��g��Q�msdn中对于对话框消息处理�q�程的返回值有如下说明�Q?br>
一般情况下�Q�对话框�q�程函数应该在处理了消息的情况下�q�回TRUE�Q�如果没有处理，则返回FALSE。如果对话框�q�程�q�回了FALSE�Q�那么对话框��理器�ؓ�q�条消息准备默认的对话操作�?br>
�? 果对话框处理了一个需要特定返回值的消息�Q�则对话框的�q�回值应该被讄��用SetWindowLong(The SetWindowLong function changes an attribute of the specified window. The function also sets a 32-bit (long) value at the specified offset into the extra window memory of a window. )后的�q�回��|��q�在�q�回TRUE之前立即�q�回�q�个倹{��注意你必须立即调用SetWindowLong�Q�这个函数用于调用窗口子�c�d��的过�E�）�Q�这会导致DWL_MSGRESULT��D��一个嵌套的对话框消�? 改写。返回��gؓ特定值的消息有：
• WM_CHARTOITEM
• WM_COMPAREITEM
• WM_CTLCOLORBTN
• WM_CTLCOLORDLG
• WM_CTLCOLOREDIT
• WM_CTLCOLORLISTBOX
• WM_CTLCOLORSCROLLBAR
• WM_CTLCOLORSTATIC
• WM_INITDIALOG
• WM_QUERYDRAGICON
• WM_VKEYTOITEM
看到没有�Q?我们的消息WM_INITDIALOG也在其中�Q�对�q�个消息�q�行处理的过�E�不能简单的�q�回TRUE表示�Ҏ��息进行了处理�Q�而是另有其意�Q�它��{化�ؓ�Q?br>
case (WM_INITDIALOG): return HANDLE_WM_INITDIALOG(hwnd, wParam, lParam, Cls_OnInitDialog);

宏HANDLE_WM_INITDIALOG定义如下�Q?br>
#define HANDLE_WM_INITDIALOG(hwnd, wParam, lParam, fn)
(LRESULT)(DWORD)(UINT)(BOOL)(fn)((hwnd), (HWND)(wParam), lParam)

对WM_INITDIALOG的处理，如果�q�回TRUE�Q�则表示讄��键盘焦点到对话框的默认控�Ӟ��否则�q�回FALSE�Q�这时好像还看不��Z��么问题，而对于我们的另外一个消息WM_COMMAND�Q�HANDLE_MSG��单的把它变成�Q?br>
case (WM_COMMAND): return HANDLE_WM_COMMAND(hwnd, wParam, lParam, Cls_OnCommand);

宏HANDLE_WM_COMMAND定义如下�Q?br>
#define HANDLE_WM_COMMAND(hwnd, wParam, lParam, fn)
((fn)((hwnd), (int)(LOWORD(wParam)), (HWND)(lParam), (UINT)HIWORD(wParam)), 0L)

�? 题出来了�Q�我们的Cls_OnCommand�׃��是个void型的函数�Q�是没有�q�回值的�Q�因此windows默认�q�种消息处理�q�程必须�q�回一�?��|��而返 �?��g��p��C�我们的消息�q�程不处理这个消息么�Q�这个矛盾是HANDLE_MSG无法解决的。怎么办才能��消息�q�程在处理完WM_COMMAND消息之后正确的返回一个TRUE呢？ �{�案是��用另一个windowsx.h中的宏：SetDlgMsgResult(hwnd, msg, result)

�q�个宏定义如下：

#define SetDlgMsgResult(hwnd, msg, result) ((
(msg) == WM_CTLCOLORMSGBOX ||
(msg) == WM_CTLCOLOREDIT ||
(msg) == WM_CTLCOLORLISTBOX ||
(msg) == WM_CTLCOLORBTN ||
(msg) == WM_CTLCOLORDLG ||
(msg) == WM_CTLCOLORSCROLLBAR ||
(msg) == WM_CTLCOLORSTATIC ||
(msg) == WM_COMPAREITEM ||
(msg) == WM_VKEYTOITEM ||
(msg) == WM_CHARTOITEM ||
(msg) == WM_QUERYDRAGICON ||
(msg) == WM_INITDIALOG
) ? (BOOL)(result) : (SetWindowLongPtr((hwnd), DWLP_MSGRESULT, (LPARAM)(LRESULT)(result)), TRUE))

�Q�有没有注意刎ͼ�里面多了一个WM_CTLCOLORMSGBOX �Q?�q�个消息�?6位WinAPI中的消息�Q�一度被转换为Win32 API的一个消息；现在在最新的32位API中已�l�被删除了；保留它可能考虑到兼�Ҏ��的问题�Q�这里不做进一步讨论）
�? 在看��C��Q�如果对话框�q�程处理的消息恰巧�ؓ�q�回特定��g��的一个，则如实返回result�Q�不要被前面的BOOL蒙蔽�Q�BOOL在头文�g中的定义实际上是一个int型，一旦需要返回非TRUE或FALSE的其他��|��照样可以�Q�这��P��我们的Cls_OnInitDialog��p��够正��的�q�回它的BOOL��g��Q? 而Cls_OnCommand在处理之后，也可以由后面的逗号表达式正��的�q�回一个TRUE表示消息已处理�?br>
在《Windows核心�~�程》一书中�Q�大牛Jeffrey自己定义了一个宏�Q��SetDlgMsgResult宏的使用更加方便�Q?br>
#define chHANDLE_DLGMSG(hwnd, message, fn)
case (message): return (SetDlgMsgResult(hwnd, uMsg,
HANDLE_##message((hwnd), (wParam), (lParam), (fn))))

可见�q�个宏只是简单的对SetDlgMsgRseult宏进行了��装�?br>
�q�样�Q�我们最�l�的代码可以写成�Q?br>
LRESULT CALLBACK Dlg_Proc (HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
chHANDLE_DLGMSG(hwnd, WM_INITDIALOG, Cls_OnInitDialog); // 使用大牛的chHANDLE_DLGMSG�?br>chHANDLE_DLGMSG(hwnd, WM_COMMAND, Cls_OnCommand);
}

return false;
}

下面把原来程序整个框架列出来�Q?br>
LRESULT CALLBACK Dlg_Proc(HWND hwnd, UNIT umsg, WPARAM wparam, LPARAM lparam)
{
switch(msg)
{
case WM_COMMAND: // 每个case都被一个message cracker代替�Q�这里��用大牛同志的
// do something; // chHANDLE_DLGMSG宏；�q�个宏负责对消息�{�选，处理�q�返回相应的�?br> return true;

case WM_INITDIALOG:
// do something;
return xxxx;
}

return false; // 如果消息不在我们的DlgProc�q�程中被处理�Q�则告诉调用�q�个DlgProc的消息，
} //告诉�pȝ��的对话框��理器，�q�个消息我们不处理，交给你了

�Ҏ��一下，消息分流器的作用不言自明�?br>
以上只是介绍了消息分��器的部分应用，更多创造性的用法�q�等你自己在实践中发掘�?br>
下面列出一些有用的参考资料：

http://support.microsoft.com/default.aspx?scid=kb;en-us;83456 介绍了STRICT宏定义以及windowsx.h
http://www.codeproject.com/win32/msgcrackwizard.asp 提供message cracker wizard的下载，而且附有源代�?br>《windows核心�~�程》windows�pȝ��~�程�Q�就跟定大牛�?:> 他在自己的sample中大量��用了message cracker

�?+ 2008-02-04 02:53 发表评论

链接错误LNK2001

�?+ — Sun, 03 Feb 2008 16:51:00 GMT

学习VC�Q�＋时经�怼�遇到链接错误LNK2001�Q�该错误非常讨厌�Q�因为对�?
�~�程者来��_��最好改的错误莫�q�于�~�译错误�Q�而一般说来发生连接错误时�Q?
�~�译都已通过。��生连接错误的原因非常多，��其LNK2001错误�Q�常�怋��Z��
明其所以然。如果不深入地学习和理解VC�Q�＋�Q�要��x��正连接错误LNK2001�?
常困难�?
　　初学者在学习VC�Q�＋的过�E�中�Q�遇到的LNK2001错误的错误消息主要�ؓ�Q?
　　unresolved external symbol “symbol”�Q�不��定的外�?#8220;�W�号”�Q��?
　　如果�q�接�E�序不能在所有的库和目标文�g内找到所引用的函数、变量或
标签�Q�将产生此错误消息。一般来��_��发生错误的原因有两个�Q�一是所引用
的函数、变量不存在、拼写不正确或者��用错误；其次可能使用了不同版�?
的连接库�?
　　以下是可能��生LNK2001错误的原因：
　　一�Q�由于编码错误导致的LNK2001�?
　　1�Q�不相匹配的�E�序代码或模块定�?.DEF)文�g能导致LNK2001。例�?
如果在C�Q�＋源文件内声明了一变量“var1”�Q�却试图在另一文�g内以变量
“VAR1”讉K��该变�?��发生该错误�?
　　2�Q�如果��用的内联函数是在.CPP文�g内定义的�Q�而不是在头文件内�?
义将��D��LNK2001错误�?
　　3�Q�调用函数时如果所用的参数�c�d��同函数声明时的类型不�W�将会��?
LNK2001�?
　　4�Q�试图从基类的构造函数或析构函数中调用虚拟函数时��会��D��LNK2001�?
　　5�Q�要注意函数和变量的可公用性，只有全局变量、函数是可公用的�?
　　静态函数和静态变量具有相同的使用范围限制。当试图从文件外部访�?
��M��没有在该文�g内声明的静态变量时��导致编译错误或LNK2001�?
　　函数内声明的变量(局部变�? 只能在该函数的范围内使用�?
　　C�Q�＋的全局帔R��只有静态连接性能。这不同于C�Q�如果试囑֜�C�Q�＋�?
多个文�g内��用全局变量也会产生LNK2001错误。一�U�解决的�Ҏ��是需要时�?
头文件中加入该常量的初始化代码，�q�在.CPP文�g中包含该头文�Ӟ��另一�U?
�Ҏ��是��用时�l�该变量赋以常数�?
　　二．�׃��~�译和链接的讄��而造成的LNK2001
　　1�Q�如果编译时使用的是/NOD(/NODEFAULTLIB)选项�Q�程序所需要的�q�行
库和MFC库在�q�接时由�~�译器写入目标文件模块，但除非在文�g中明��包�?
�q�些库名�Q�否则这些库不会被链接进工程文�g。在�q�种情况下��?NOD��导
致错误LNK2001�?
　　2�Q�如果没有�ؓwWinMainCRTStartup讑֮��E�序入口�Q�在使用Unicode和MFC
时将得到“unresolved external on _WinMain@16”的LNK2001错误信息�?
　　3�Q��?MD选项�~�译�?既然所有的�q�行库都被保留在动态链接库之内�Q?
源文件中�?#8220;func”的引用，在目标文仉��卛_��“__imp__func” 的引用�?
如果试图使用静态库LIBC.LIB或LIBCMT.LIB�q�行�q�接�Q�将在__imp__func上发
生LNK2001�Q�如果不使用/MD选项�~�译�Q�在使用MSVCxx.LIB�q�接时也会发生LNK2001�?
　　4�Q��?ML选项�~�译�Ӟ��如用LIBCMT.LIB链接会在_errno上发生LNK2001�?
　　5�Q�当�~�译调试版的应用�E�序�Ӟ��如果采用发行版模态库�q�行�q�接也会�?
生LNK2001�Q�同��P��使用调试版模态库�q�接发行版应用程序时也会产生相同�?
问题�?
　　6�Q�不同版本的库和�~�译器的混合使用也能产生问题�Q�因为新版的库里�?
能包含早先的版本没有的符号和说明�?
　　7�Q�在不同的模块��用内联和非内联的�~�译选项能够��D��LNK2001。如�?
创徏C�Q�＋库时打开了函数内联（/Ob1�?Ob2)�Q�但是在描述该函数的相应�?
文�g里却关闭了函数内联（没有inline关键字）�Q�这时将得到该错误信息�?
为避免该问题的发生，应该在相应的头文件中用inline关键字标志内联函数�?
　　8�Q�不正确�?SUBSYSTEM�?ENTRY讄��也能��D��LNK2001�?
　　其实�Q��生LNK2001的原因还有很多，以上的原因只是一部分而已�Q�对�?
学者来说这些就够理解一阵子了。但是，分析错误原因的目的是��Z��避免�?
误的发生。LNK2001错误虽然比较困难�Q�但是只要注意到了上�q�问题，�q�是�?
够避免和予以解决的。　　
-----------------------------------
�?

�?+ 2008-02-04 00:51 发表评论