口,再调用UpdateWindow(),发出WM_PAINT消息。(5)回到WinMain()中,调用pApp-＞Run(),进入消息循环,通过API函数 GetMessage()获得消息,由Tr

口,再调用UpdateWindow(),发出WM_PAINT消息。
(5)回到WinMain()中,调用pApp->Run(),进入消息循环,通过API函数 GetMessage()
获得消息,由TranslateMessage()进行键盘消息转换,DispatchMessage()派送消息到CWnd :: De-
fWindowProc()中,DefWindowProc()按照消息映射表的定义将消息分发到各相应消息处理函
数;如果消息队列为空,则Run()调用CWinApp :: OnIdle()进行空闲处理,重定义OnIdle()可以
处理后台程序(低优先级)。
(6)若用户选择菜单File/Close,则程序收到WM_COLSE消息,调用 :: DestroyWindow()发
出WM_DESTROY 消息,然后调用PostQuitMessage(),发出WM_QUIT消息,此时Run()会结
束其内部消息循环,调用Exitlnstance()。
(7)最后,返回WinMain(),执行WinTerm(),结束程序运行。
从上述过程可以看出,在基于Windows API的应用程序设计中所做的工作,如定义、创建、
注册窗口类,消息的获取、解释和派送以及窗口函数,在MFC程序中都出现了,只是大部分烦琐
的工作由应用程序框架自动完成,甚至在程序中看不到这些代码,这是MFC虚函数机制的功
劳。基类的虚函数完成了大部分的工作,在一般情况下不需要做修改,也就不需要重定义它们,
因此在派生类中看不到这些函数。因此,可以说CWinApp对象完成了WinMain()的工作,而
CFrameWnd对象完成了WndProc()的工作。
下面就MFC程序再做几点解释:
(1)每个MFC应用都有stdafx.h头文件,由应用程序向导自动生成。
(2)头文件afxwin.h包含在stdafx.h中,其内部又包含了其他头文件。这些头文件声明了
所有的MFC类。
(3)每一个MFC应用程序都包含惟一的CWinApp对象,代表应用程序本身。CWinApp类
封装了Windows应用程序的概念,是应用程序的主线程,控制整个应用程序的执行。
(4)MFC应用程序中看不到WinMain()入口函数,它被封装在应用程序框架里,运行时自
动调用;也看不到RegisterClass()、CreateWindow()、GetMessage()、DispatchMessage()以及Wnd-
Proc()函数,它们都是由应用程序框架提供或由函数嵌套调用完成的。
从以上分析可见,MFC应用程序框架为程序生成了很多关系复杂的代码,简化了Windows
程序设计、可以让开发人员集中精力于特定应用领域内的数据结构设计、算法设计和代码编写。
上述过程看起来非常复杂,涉及很多类和很多函数。对于初学者来说,不必关心具体的过
程,只需借助MFC向导,定义数据成员和消息映射表并定义消息处理函数即可。

3.2.2 MFC消息映射

第2章中指出,MFC引入消息映射(message map)机制,简化并增强了消息处理功能。MFC
内部通过一系列非常复杂的宏处理消息映射,使得定义和使用消息映射表相对简单,这通过以下
3个步骤完成:
(1)在头文件的类声明中添加DECLARE_MESSAGE_MAP宏声明消息映射。