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做的工作太多了,缺了它我们要补上的代码可不是一两个分支的问题,而是上百个分支了!在这个实验中,我们根本不可能把它补全。

上页:第04章 第一个窗口程序 · 4.4 实验(2) 下页:第05章 使用资源 · 5.1 菜单和加速键(1)

第04章 第一个窗口程序

版权所有 © 中山市飞娥软件工作室 证书:粤ICP备09170368号