按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
int CALLBACK WinMain （HINSTANCE hInstance； HINSTANCE hPrevInstance；
LPSTR lpCmdLine； int nCmdShow）
｛
if （！hPrevInstance）
if （！InitApplication （hInstance））
return （FALSE）；
if （！InitInstance （hInstance； nCmdShow））
return （FALSE）；
。。。
｝
//…………………………………………………………………………………………………………………………………
BOOL InitApplication （HINSTANCE hInstance）
｛
WNDCLASS wc；
。。。
return （RegisterClass （&wc））；
｝
//…………………………………………………………………………………………………………………………………
BOOL InitInstance （HINSTANCE hInstance； int nCmdShow）
｛
_hWnd = CreateWindow （。。。）；
。。。
｝
两个函数（InitAppl ication 和InitInstance ）的名称别具意义：
Windows 3。x
■ 在 时代，窗口类别只需注册一次，即可供同一程序的后续每一个
instance
执行实例 （ ）使用（之所以能够如此，是因为所有进程共在一个地址空
RegisterClass
间中），所以我们把 这个动作安排在「只有第一个执行个体才会
17
…………………………………………………………Page 80……………………………………………………………
进入」的InitAppl ication 函数中。至于此一进程是否是某个程序的第一个执行
实例，可由WinMain 的参数hPrevInstance 判断之；其值由系统传入。
■ 产生窗口， 是每一个执行实例（ instance ） 都得做的动作， 所以我们把
Create Window 这个动作安排在「任何执行实例都会进入」的InitInstance 函数中。
Windows NT Windows 95 Win32
以上情况在 和 中略有变化。由于 程序的每一个执行实
instance Win32
例 （ ）有自己的地址空间，共享同一窗口类别已不可能。但是由于 系统令
hPrevInstance 0 RegisterClass Create Window
永远为 ，所以我们仍然得以把 和 按旧习惯
安排。既符合了新环境的要求，又兼顾到了旧源代码的兼容。
InitAppl ication 和InitInstance 只不过是两个自定函数，为什么我要对此振振有词呢？原
因是MFC 把这两个函数包装成CWinApp 的两个虚拟成员函数。第６章「MFC 程序的
生与死」对此有详细解释。
消息循环
初始化工作完成后，WinMain 进入所谓的消息循环：
while （GetMessage （&msg；。。。）） ｛
TranslateMessage （&msg）； // 转换键盘消息
DispatchMessage （&msg）； // 分派消息
｝
其中的TranslateMessage 是为了将键盘消息转化，Dispat chMessage 会将消息传给窗口函
数去处理。没有指定函数名称，却可以将消息传送过去，岂不是很玄？这是因为消息发
生之时，操作系统已根据当时状态，为它标明了所属窗口，而窗口所属之窗口类别又已
wc lpf nWndProc Dispat chMessage
。 ）
经明白标示了窗口函数（也就是 所指定的函数 ，所以
图 所示 Dispa tchMessage USER
自有脉络可寻。请注意 1…2 ， 经过 模块的协助，才把消
息交到窗口函数手中。
消息循环中的GetMessage 是Windows 3。x 非强制性（non…preemptive ）多任务的关键。应
用程序藉由此动作，提供了释放控制权的机会：如果消息队列上没有属于我的消息，我
就把机会让给别人。透过程序之间彼此协调让步的方式，达到多任务能力。Windows 95 和
…………………………………………………………Page 81……………………………………………………………
Windows NT 具备强制性（preemptive ）多任务能力，不再非靠GetMessage 释放CPU 控
制权不可，但程序写法依然不变，因为应用程序仍然需要靠消息推动。它还是需要抓消
息！
窗口的生命中枢 ：窗口函数
消息循环中的Dispat chMessage 把消息分配到哪里呢？它透过USER 模块的协助，送到
switch case
该窗口的窗口函数去了。窗口函数通常利用 / 方式判断消息种类，以决定处置
方式。由于它是被Windows 系统所调用的（我们并没有在应用程序任何地方调用此函
数），所以这是一种call back 函数，意思是指「在你的程序中，被Windows 系统调用」
的函数。这些函数虽然由你设计，但是永远不会也不该被你调用，它们是为Windows 系
统准备的。
程序进行过程中，消息由输入装置，经由消息循环的抓取，源源传送给窗口并进而送到
窗口函数去。窗口函数的体积可能很庞大，也可能很精简，依该窗口感兴趣的消息数量
多寡而定。至于窗口函数的形式，相当一致，必然是：
LRESULT CALLBACK WndProc （HWND hWnd；
UINT message；
WPARAM wParam；
LPARAM lParam）
switch case def ault
注意，不论什么消息，都必须被处理，所以 / 指令中的 ： 处必须调用
Def WindowProc，这是Windows 内部预设的消息处理函数。
窗口函数的wParam 和lParam 的意义，因消息之不同而异。wParam 在16 位环境中是
16 位，在32 位环境中是32 位。因此，参数内容（格式）在不同操作环境中就有
了变化。
我想很多人都会问这个问题：为什么Windows Programming Modal 要把窗口函数设计为
一个call back 函数？为什么不让程序在抓到消息（GetMessage ）之后直接调用它就好
了？原因是，除了你需要调用它，有很多时候操作系统也要调用你的窗口函数（例如当
19
…………………………………………………………Page 82……………………………………………………………
某个消息产生或某个事件发生）。窗口函数设计为callback 形式，才能开放出一个接口
给操作系统叫用。
消息映射 （ ）的雏形
Message Map
有没有可能把窗口函数的内容设计得更模块化、更一般化些？下面是一种作法。请注意，
MFC
以下作法是 「消息映射表格」（第９章）的雏形，我所采用的结构名称和变量名称，
都与MFC 相同，藉此让你先有个暖身。
MSGMAP ENTR Y dim
_
首先，定义一个 结构和一个 宏：
struct MSGMAP_ENTRY ｛
UINT nMessage；
LONG （*pfn）（HWND； UINT； WPARAM； LPARAM）；
｝；
#define dim （x） （sizeof（x） / sizeof（x ＇0＇））
MSGMAP_ENTR Y pf n
请注意 的第二元素 是一个函数指针，我准备以此指针所指之函
数处理nMessage 消息。这正是对象导向观念中把「资料」和「处理资料的方法」封装
起来的一种具体实现，只不过我们用的不是C＋＋ 语言。
接下来，组织两个数组_messageEntries ＇ ＇ 和_mandEntries ＇ ＇，把程序中欲处理的消
息以及消息处理例程的关联性建立起来：
// 消息与处理例程之对照表格
struct MSGMAP_ENTRY _messageEntries＇＇ =
｛
WM_CREATE； OnCreate；
WM_PAINT； OnPaint；
WM_SIZE； OnSize；
WM_MAND； Onmand；
WM_SETFOCUS； OnSetFocus；
WM_CLOSE； OnClose；
WM_DESTROY； OnDestroy；
｝ ； ↑ ↑
这是消息 这是消息处理例程
20
…………………………………………………………Page 83……………………………………………………………
// mand…ID
与处理例程之对照表格
struct MSGMAP_ENTRY _mandEntries =
｛
IDM_ABOUT； OnAbout；
IDM_FILEOPEN； OnFileOpen；
IDM_SAVEAS； OnSaveAs；
｝ ； ↑ ↑
这是WM_MAND 命令项这是命令处理例程
于是窗口函数可以这么设计：
//………………………………………………………………………………………………………………………………………………………………………………………
// 窗口函数
//………………………………………………………………………………………………………