WIN32汇编第04章 第一个窗口程序 · 4.4 实验(3)
WIN32汇编语言教程：第04章 第一个窗口程序 · 4.4 实验(3)
实验2. 全部消息都经过消息循环吗
在做这个实验之前,读者已经知道并不是所有的消息都是经过消息循环的,它们中的有些是Windows直接发送到窗口过程的,上一个实验中就已经可以看到GetMessage返回的次数明显地比调用窗口过程的次数少,这意味着窗口过程有很多次是由Windows直接调用的。
这次,我们用极端的方式来验证,先把消息循环中的DispatchMessage去掉,这样GetMessage得到的消息将不会再被送到窗口过程了,窗口过程收到的就是由Windows直接调用的了。改变后的源代码见所附光盘中的Chapter04\MsgWindow02目录。
编译后,同样先打开记事本,再执行MsgWindow,然后将鼠标移过MsgWindow窗口,并尝试着单击“关闭”按钮和双击等各种动作,结果是窗口过程还是在被调用：
WndProc: [0084]WM_NCHITTEST 00000000 007e0088 WndProc: [0020]WM_SETCURSOR 0026030c 02000001 WndProc: [0084]WM_NCHITTEST 00000000 006c0070 WndProc: [0020]WM_SETCURSOR 0026030c 02000001 ...
由于没有了DispatchMessage,大部分消息被忽略了,窗口就停在了屏幕上,不能进行移动、缩放或关闭等操作,但还是有一部分消息直接由Windows发送给窗口过程,它们是鼠标位置测试的WM_NCHITTEST消息和要求设置光标的WM_SETCURSOR消息,所以在鼠标移动到边框的时候,鼠标光标还是会变成双箭头的样子。
另外,尝试着单击别的窗口来切换焦点,然后再单击标题栏来重新激活窗口,可以发现WM_MOUSEACTIVATE,WM_ACTIVATE和WM_KILLFOCUS等消息也是不经过消息循环的。接下来,把一个窗口移动到MsgWindow窗口前覆盖它的位置,再移开,可以发现WM_SYNCPAINT和WM_ERASEBKGND等消息也是由Windows直接发给窗口过程的。
最后,关闭窗口,当然这个窗口只能用Ctrl+Alt+Del键在任务管理器中关闭了！
实验3. TranslateMessage有什么用
首先执行实验1的MsgWindow,在窗口上敲几个键,每次敲一个键,得到的消息是：WM_KEYDOWN,WM_CHAR和WM_KEYUP。如果按下键盘不放,则首先得到一个WM_KEYDOWN,接下来就是重复的WM_CHAR和WM_KEYUP消息,直到放开键盘为止,最后才会看到一个WM_KEYUP。显示如下：
WndProc: [0100]WM_KEYDOWN 00000041 001e0001 WndProc: [0102]WM_CHAR 00000061 001e0001 WndProc: [0101]WM_KEYUP 00000041 c01e0001
在WM_KEYDOWN和WM_KEYUP消息中,wParam中是按键的扫描码,上面的数据是按下了键“A”得到的,00000041h是“A”的扫描码,到了WM_CHAR消息中,wParam中就是已经转换过的ASCII码61了,代表输入的是小写的字母“a”。
好！现在从程序中去掉TranslateMessage语句（修改以后的源代码放在Chapter04\MsgWindow03目录中）,然后看这个程序的运行结果,同样,按几次键以及按下键盘不放,我们发现：这中间的区别就是少了WM_CHAR,所以只有在处理键盘输入要用到转换后的ASCII码的时候,TranslateMessage函数才是有用的,在别的时候完全可以省略这个语句。这个函数的功能就是看到WM_KEYDOWN的时候把消息检查一下,然后根据键值将一条新的WM_CHAR或WM_SYSCHAR消息放入消息循环中。
实验4. DefWindowProc做了什么工作
现在把DefWindowProc语句去掉（源代码详见Chapter04\MsgWindow04目录）,然后再以同样的方法运行,窗口根本就没有出现！看记事本中出现了什么：
Creating Window... WndProc: [0024]WM_GETMINMAXINFO 00000000 0012fda4 WndProc: [0081]WM_NCCREATE 00000000 0012fd8c WndProc: [0082]WM_NCDESTROY 00000000 00000000 CreateWindow end Showing Window... ShowWindow end Updating Window... UpdateWindow end Getting Message...
原来在建立窗口的时候执行到WM_NCCREATE消息后窗口就摧毁掉了,看WM_NCCREATE的说明：The DefWindowProc function returns TRUE,原来需要返回1来表示执行成功,所以需要处理WM_NCCREATE并返回1,现在在窗口过程中加上下列分支：
.elseif eax == WM_NCCREATE
mov eax,1
ret
接着编译后执行,怎么编译不成功了？不能写exe文件?原来上次的程序还停留在消息循环中没有退出来,让我们在任务管理器中将它终止再编译,成功了！
好！现在继续执行,窗口成功建立了,但似乎陷入了死循环,因为记事本上不停地有消息冒出来,而且只是冒出WM_PAINT消息来,为什么呢？原来WM_PAINT消息是不能不处理的,也不能丢弃,只要Windows认为窗口的客户区需要绘画（或者说是无效的）,它就会不停地向窗口发送WM_PAINT消息,一般WM_PAINT消息的处理中用BeginPaint和EndPaint会隐含地让客户区有效,如果不用BeginPaint/EndPaint,程序必须显式地把客户区设置为有效,Windows才不会再发送WM_PAINT消息。这个函数是ValidateRect,现在在分支中再加上处理WM_PAINT的代码：
.elseif eax == WM_PAINT
invoke ValidateRect,hWnd,NULL
再编译执行,现在程序可以正常执行下去了,记事本上出现的信息也显示程序停留在了GetMessage处,一切正常。但是,窗口在哪里呢,屏幕上什么都没有,隐身了？把鼠标移到窗口原来应该出现的地方,记事本中熟悉的WM_NCHITTEST和WM_SETCURSOR消息出现了,原来窗口还在那里,只不过没有了DefWindowProc的处理,窗口的绘画等所有工作都没有做,窗口的边框与客户区等所有东西连画都没有画上去,所以窗口是存在的,但我们看不到它！
是不是再加上WM_NCPAINT消息自己画边框呢,这就不是这个实验的内容了。我们已经知道,DefWindowProc做的工作太多了,缺了它我们要补上的代码可不是一两个分支的问题,而是上百个分支了！在这个实验中,我们根本不可能把它补全。