按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
来源：电子工业出版社 作者：罗云彬 上一页 回书目 下一页
上一页 回书目 下一页
第6章 定时器
6。3 取Windows时间
很多读者看到“定时器”这个词的时候往往就联想到时钟，笔者也曾是如此，但是经过6。2节的介绍后就可以发现，定时器是不能用来构造时钟的，定时器用于时钟程序中只能是用在定时刷新屏幕这个功能上，要得到系统的时间还是要靠别的方法。
在Win32编程中，和获取系统时间相关的函数有3个：
invoke GetLocalTime；lpSystemTime
invoke GetSystemTime；lpSystemTime
invoke GetTickCount
它们之间的区别是：
GetTickcount返回的是本次Windows启动以来的ms数，得到的时间数值直接在eax中返回，由于这是一个32位的整数，可以表示的范围是1～ffffffffh ms，所以当Windows连续运行49。7天以后，计数器会清零并重新开始。
GetLocalTime返回当前的时间，GetSystemTime返回当前的格林威治标准时间，这两个函数返回的时间数据包括年、月、日、时、分、秒、毫秒以及星期，数据比较多，所以无法放在eax中返回，应用程序需要预先设置一个SYSTEMTIME结构的缓冲区，并将缓冲区地址lpSystemTime当参数传递给函数，函数会把时间数据返回到这个缓冲区中。
SYSTEMTIME结构的定义如下：
SYSTEMTIME STRUCT
wYear WORD ？ ；年
wMonth WORD ？ ；月
wDayOfWeek WORD ？ ；星期，0＝星期日，1＝星期一，……
wDay WORD ？ ；日
wHour WORD ？ ；时
wMinute WORD ？ ；分
wSecond WORD ？ ；秒
wMilliseconds WORD ？ ；毫秒
SYSTEMTIME ENDS
需要注意的是，结构中的字段全部是word类型的，而Win32程序中用的往往是dword型变量，所以在使用这些数据之前往往要先把它们转换为dword类型，用movzx指令就可以很方便地完成这个工作，如movzx eax；stSystemTime。wYear将wYear字段扩展到32位后放到eax中。
和获取系统时间的函数相对应，可以用下面的两个函数设置系统时间：
invoke SetLocalTime；lpSystemTime
invoke SetSystemTime；lpSystemTime
同样，SetLocalTime中的参数代表本地时间，SetSysTime中的参数代表格林威治标准时间，在调用函数之前，要把需要设置的时间放到一个SYSTEMTIME结构中并把结构地址当做参数传递给Windows。
来源：电子工业出版社 作者：罗云彬 上一页 回书目 下一页
上一页 回书目 下一页
第7章 图形操作
7。1 GDI原理（1）
Windows是基于图形界面的，所以在Win32编程中，图形操作是最常用的操作。GDI的意义在于将程序对图形界面的操作和硬件设备隔绝开来，在程序中可以将所有的图形设备都看成是虚拟设备，包括视频显示器和打印机等，然后通过GDI函数用同样的方法去操作它们，由Windows负责将函数调用转化成针对具体硬件的操作。只要一个设备提供了和Windows兼容的驱动程序，它就可以被看做是一个标准的设备。以前在DOS系统下写应用程序的时候，如果要进行图形操作，那么就要考虑到市场上每种显示卡的不同，否则在装配某种显卡的计算机上就可能无法正常运行，对汇编程序员来说，这真是一个恶梦。在Win32编程中，正是GDI函数让这个恶梦成为历史。
GDI函数全部包括在GDI32。DLL中，在编程的时候，注意要在源程序的开头加上相应的包含语句：
include gdi32。inc
includelib gdi32。lib
和GDI相关的内容真是太庞大了，只要查看一下gdi32。inc文件就可以发现，函数的总数达到了300多个，和GDI相关的数据结构也非常多，要完全深入GDI编程，用上本书的全部篇幅可能也不够。在本章中，笔者希望通过几个例子，让读者能了解GDI的原理和基本的使用方法。
归纳起来，GDI操作可以从3个方面去了解——When，Where和How：
● When——指的是进行图形操作的时机，究竟什么时刻最适合程序进行图形操作呢？在7。1。1节“GDI程序的结构”中，将探讨这个问题。
● Where——指的是图形该往哪里画，既然Windows隔离了硬件图形设备，那么该把什么地方当做“下笔”的地方呢？7。1。2节的“设备环境”就是解答。
● How——了解了上面两个问题后，最后还要知道“如何画”，这就涉及如何使用大部分GDI函数的问题了，在本章余下来的篇幅中，将集中讨论这个问题。
7。1。1 GDI程序的结构
1。 客户区的刷新
正如上面所说的，本节讨论的是“When”的问题，读者可能会问：为什么会有这个问题，如果要向窗口输出图形，程序想在什么时候输出那就是什么时候，难道这个时刻还有规定不成？
但这个问题似乎不能这样来问，让我们来考虑这些情况：在DOS操作系统中编程的时候，程序把文字或图形输出到屏幕，在输出新的内容之前，这些内容总是保留在屏幕原处，这些内容会被意外覆盖的惟一情况是激活一个TSR程序，但TSR程序在退出之前有义务恢复原来的屏幕，如果它无法恢复屏幕的内容，那么这是它的责任，我们不会在自己的程序中去考虑屏幕内容会无缘无故消失这种情况，所以可以把屏幕看成是应用程序私有的。
如果程序输出的内容过多，如用dir显示一个含有很多文件的目录，用户根本无法看清快速上翻的屏幕，这时程序可以设计一个参数来暂停一下，如dir /p。这已经是DOS程序最“体贴”的做法了，如果用户想回过头去看已经滚出屏幕的内容，那可对不起，只能再执行一遍了！
所以对DOS程序来说，程序想在什么时候输出信息那就是什么时候，根本不存在When这个问题。
但在Windows操作系统中，屏幕是多个程序“公用”的，用户程序不要指望输出到窗口中的内容经过一段时间后还会保留在那里，它们可能被别的东西覆盖，如其他窗口、鼠标箭头或下拉的菜单等。在Windows中，恢复被覆盖内容的责任大部分属于用户程序自己，理由很简单：Windows是个多任务的操作系统，假如程序B覆盖了程序A的窗口内容，覆盖掉的内容由程序B负责恢复的话，它就必须保存它覆盖掉的内容，但是在它将保存的内容恢复之前，程序A也在运行，并可能在程序B恢复以前已经向它自己的窗口输出新的内容，结果当程序B恢复它保存的窗口内容时，保存的内容可能是过时的（而DOS的情况就不同，TSR程序激活的时候，用户程序是被挂起的），所以最好的办法就是让程序A自己来决定如何恢复。
Windows系统采用的方法是：当Windows检测到窗口被覆盖的地方需要恢复的时候，它会向用户程序发送一个WM_PAINT消息，消息中包括了需要恢复的区域，然后由用户程序来决定如何恢复被覆盖的内容。
如果程序因为忙于处理其他事务以至于无法及时响应WM_PAINT消息，那么窗口客户区原先被覆盖的地方可能会被Windows暂时画成一块白色（或者背景色）的矩形，或者根本就是保留被覆盖时的情形，直到程序有时间去响应WM_PAINT消息为止。我们常常可以看到这种情况发生在死锁程序的客户区内，这就是因为死锁的程序无法响应WM_PAINT消息来恢复客户区造成的。
所以对于“When”这个问题，答案是：程序应该在Windows要求的时候绘画客户区，也就是在收到WM_PAINT消息的时候。如果程序需要主动刷新客户区，那么可以通过调用InvalidateRect等函数引发一条WM_PAINT消息，因为在WM_PAINT消息中刷新客户区的代码是必须存在的，所以用这种看似“舍近求远”的办法实际上可以节省一份重复的代码。即使是在游戏程序这种“主动刷新”远远多于“被动刷新”的程序中，只要窗口有被其他东西覆盖的可能，那么这个原则就是适用的。
2。 GDI程序的结构
对于Win32程序来说，WM_PAINT消息随时可能发生，这就意味着，程序再也不能像在DOS下一样输出结果后就不管了，反过来，程序在任何时刻都应该知道如何恢复整个或局部客户区中以前输出的内容，本着这个要求，可以按图7。1所示来安排程序结构。
图7。1 GDI程序的结构
如果程序的功能比较简单，可以采取图中左边的A程序结构，即计算及刷新整个客户区的代码全部安排在WM_PAINT消息中完成，这样，每次当客户区的全部或部分需要被更新的时候，程序重新执行整个生成客户区屏幕数据的功能模块并刷新客户区。这种结构适用于功能模块很短小且执行速度很快的情况，整个过程的时间最好不超过几百ms，否则，用户会在一个明显的等待时间后才看到程序把客户区中的“空洞”补上。考虑一个极端的情况：当程序输出的内容是经过千辛万苦才算出来的——这不是一件奇怪的事情，计算圆周率的程序就要动辄计算几个小时——那么即使客户区被别的窗口覆盖掉一点点，程序也要经过整个计算过程后才能重画客户区，而且在这个过程中，程序还没有从WM_PAINT消息返回，以至于无法处理其他消息，结果程序就会以客户区中有个空洞的难看姿势呆在屏幕上一动不动达几个小时！
当生成屏幕数据的功能模块有些复杂的时候，如刚才计算圆周率的例子，就应该考虑采用图中B程序所示的结