MFC入门指南：从Win32程序到C++特性与MFC应用

需积分: 10 77 浏览量更新于2024-07-20 收藏 16.22MB PDF 举报

深入浅出MFC是一本专注于Microsoft Foundation Classes (MFC)的教程书籍，它旨在帮助读者理解和掌握Windows应用程序的开发技术。该书以Windows 32位应用程序开发为核心，从基础概念到高级特性，逐步引导读者步入MFC的世界。第0章概述了书籍的目标读者，强调了所需的预备知识，如熟悉C++编程基础，以及需要具备的Windows开发环境，如Visual Studio。书中还明确了符号约定，并简述了磁盘内容和安装方法，以及范例程序的作用，以便读者更好地理解和实践。第一篇"勿在浮砂筑高台-本书技术前提"介绍了Win32程序开发的基本概念，包括程序开发流程、所需函数库和头文件，以及消息驱动架构。读者会学习到如何创建Win32程序，如如何通过`WinMain`作为程序的入口点，理解窗口类的注册和窗口创建过程，以及消息循环的重要性。对话框的使用、模块定义文件和资源描述文件在这一部分也有所涉及。同时，还讨论了Console程序的区别和开发技巧，如JBACKUP和MFCCON示例，以及CRuntimeLibrary的多线程版本和进程与线程的概念。第二章着重于C++语言的高级特性，如类、封装、继承、虚函数和多态，帮助读者理解面向对象编程的核心概念。这部分还会解析类与对象的关系，包括对象切片和虚函数的应用。此外，构造函数和析构函数的作用，四种对象生存方式，以及运行时类型信息（RTTI）在C++中的作用也被深入讲解。第三章深入探讨MFC，展示了如何利用MFC框架进行动态生成对象、异常处理、模板（包括模板函数和模板类）等高级编程技术。这部分内容涵盖了MFC的实战应用，以及模板的编译和链接过程，帮助读者熟练掌握MFC库在Windows应用程序开发中的角色。深入浅出MFC提供了一个全面且实用的学习路径，从基础的Win32编程原理到高级的MFC技术和C++特性，适合希望提升Windows应用程序开发能力的开发者阅读。通过本书，读者不仅能掌握Windows应用程序的开发技术，还能对C++编程有更深的理解。

深入浅出 MFC

#0007 jjhouricon ICON DISCARDABLE "jjhour.ico"

#0008

#0009 GenericMenu MENU DISCARDABLE

#0010 BEGIN

#0011 POPUP "&File"

#0012 BEGIN

#0013 MENUITEM "&New", IDM_NEW, GRAYED

#0014 MENUITEM "&Open...", IDM_OPEN, GRAYED

#0015 MENUITEM "&Save", IDM_SAVE, GRAYED

#0016 MENUITEM "Save &As...", IDM_SAVEAS, GRAYED

#0017 MENUITEM SEPARATOR

#0018 MENUITEM "&Print...", IDM_PRINT, GRAYED

#0019 MENUITEM "P&rint Setup...", IDM_PRINTSETUP, GRAYED

#0020 MENUITEM SEPARATOR

#0021 MENUITEM "E&xit", IDM_EXIT

#0022 END

#0023 POPUP "&Edit"

#0024 BEGIN

#0025 MENUITEM "&Undo\tCtrl+Z", IDM_UNDO, GRAYED

#0026 MENUITEM SEPARATOR

#0027 MENUITEM "Cu&t\tCtrl+X", IDM_CUT, GRAYED

#0028 MENUITEM "&Copy\tCtrl+C", IDM_COPY, GRAYED

#0029 MENUITEM "&Paste\tCtrl+V", IDM_PASTE, GRAYED

#0030 MENUITEM "Paste &Link", IDM_LINK, GRAYED

#0031 MENUITEM SEPARATOR

#0032 MENUITEM "Lin&ks...", IDM_LINKS, GRAYED

#0033 END

#0034 POPUP "&Help"

#0035 BEGIN

#0036 MENUITEM "&Contents", IDM_HELPCONTENTS, GRAYED

#0037 MENUITEM "&Search for Help On...", IDM_HELPSEARCH, GRAYED

#0038 MENUITEM "&How to Use Help", IDM_HELPHELP, GRAYED

#0039 MENUITEM SEPARATOR

#0040 MENUITEM "&About Generic...", IDM_ABOUT

#0041 END

#0042 END

#0043

#0044 AboutBox DIALOG DISCARDABLE 22, 17, 144, 75

#0045 STYLE DS_MODALFRAME | WS_CAPTION | WS_SYSMENU

#0046 CAPTION "About Generic"

#0047 BEGIN

#0048 CTEXT "Windows 95", -1,0, 5,144,8

#0049 CTEXT "Generic Application",-1,0,14,144,8

#0050 CTEXT "Version 1.0",-1,0,34,144,8

#0051 DEFPUSHBUTTON "OK", IDOK,53,59,32,14,WS_GROUP

#0052 END

程序进入点 WinMain

main

是一般 C 程序的进入点：

int main(int argc, char *argv[ ], char *envp[ ]);

{

...

}

WinMain

则是 Windows 程序的进入点：

深入浅出 MFC

int CALLBACK WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,

LPSTR lpCmdLine, int nCmdShow)

{

...

} // 在 Win32 中 CALLBACK 被定义为 __stdcall，是一种函数调用习惯，关系到参数挤压到堆栈的

次序，以及处理堆栈的责任归属。其它的函数调用习惯还有_pascal 和_cdecl

当 Windows 的「外壳」（shell，例如 Windows 3.1 的程序管理员或 Windows 95 的文件总管）侦测到

使用者意欲执行一个 Windows 程序，于是调用加载器把该程序加载，然后调用 C startup code，后者再

调用 WinMain，开始执进程序。WinMain 的四个参数由作业系统传递进来。

窗口类之注册与窗口之诞生

一开始，Windows 程序必须做些初始化工作，为的是产生应用程序的工作舞台：窗口。这没有什么困

难，因为 API 函数 CreateWindow 完全包办了整个巨大的工程。但是窗口产生之前，其属性必须先设定好。

所谓属性包括窗口的「外貌」和「行为」，一个窗口的边框、颜色、标题、位置等等就是其外貌，而窗口

接收消息后的反应就是其行为（具体地说就是指窗口函数本身）。程序必须在产生窗口之前先利用 API 函

数 RegisterClass 设定属性（我们称此动作为注册窗口类）。RegisterClass 需要一个大型数据结构

WNDCLASS 做为参数，CreateWindow 则另需要 11 个参数。

图 1-3 RegisterClass 与 CreateWindow

从图 1-3 可以清楚看出一个窗口类牵扯的范围多么广泛，其中 wc.lpfnWndProc 所指定的函数就是窗

口的行为中枢，也就是所谓的窗口函数。注意，CreateWindow 只产生窗口，并不显示窗口，所以稍后我们

必须再利用 ShowWindow 将之显示在屏幕上。又，我们希望先传送个 WM_PAINT 给窗口，以驱动窗口的绘

图动作，所以调用 UpdateWindow。消息传递的观念暂且不表，稍后再提。

请注意，在 Generic 程序中，RegisterClass 被我包装在 InitApplication 函数之中，CreateWindow

则被我包装在 InitInstance 函数之中。这种安排虽非强制，却很普遍：

int CALLBACK WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,

LPSTR lpCmdLine, int nCmdShow)

{

深入浅出 MFC

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(...);

...

}

两个函数（InitApplication 和 InitInstance）的名称别具意义：

在 Windows 3.x 时代，窗口类只需注册一次，即可供同一程序的后续每一个执行个体（instance）使

用（之所以能够如此，是因为所有进程共在一个地址空间中），所以我们把 RegisterClass 这个动作安排

在“只有第一个执行个体才会进入” 的 InitApplication 函数中。至于此一进程是否是某个程序的第一

个执行个体，可由 WinMain 的参数 hPrevInstance 判断之；其值由系统传入。

产生窗口，是每一个执行个体（instance）都得做的动作，所以我们把 CreateWindow 这个动作安排

在「任何执行个体都会进入」的 InitInstance 函数中。

以上情况在 Windows NT 和 Windows 95 中略有变化。由于 Win32 程序的每一个执行个体

（instance）有自己的地址空间，共享同一窗口类已不可能。但是由于 Win32 系统令 hPrevInstance 永

远为 0，所以我们仍然得以把 RegisterClass 和 CreateWindow 按旧习惯安排。既符合了新环境的要求，又

兼顾到了旧原始代码的兼容。

InitApplication 和 InitInstance 只不过是两个自定函数，为什么我要对此振振有词呢？原因是

MFC 把这两个函数包装成 CWinApp 的两个虚成员函数。第６章「MFC 程序的生与死」对此有详细解释。

消息循环

初始化工作完成后，WinMain 进入所谓的消息循环：

while (GetMessage(&msg,...)) {

TranslateMessage(&msg); // 转换键盘消息

DispatchMessage(&msg); // 分派消息

}

其中的 TranslateMessage 是为了将键盘消息转化，DispatchMessage 会将消息传给窗口函数去处理。

没有指定函数名称，却可以将消息传送过去，岂不是很玄？这是因为消息发生之时，操作系统已根据当时

状态，为它标明了所属窗口，而窗口所属之窗口类又已经明白标示了窗口函数（也就是 wc.lpfnWndProc 所

指定的函数)，所以 DispatchMessage 自有脉络可寻。请注意图 1-2 所示，DispatchMessage 经过 USER

模块的协助，才把消息交到窗口函数手中。

消息循环中的 GetMessage 是 Windows 3.x 非强制性（non-preemptive）多任务的关键。应用程序藉

由此动作，提供了释放控制权的机会：如果消息队列上没有属于我的消息，我就把机会让给别人。通过程

序之间彼此协调让步的方式，达到多任务能力。Windows 95 和 Windows NT 具备强制性（preemptive）

多任务能力，不再非靠 GetMessage 释放 CPU 控制权不可，但程序写法依然不变，因为应用程序仍然需要

靠消息推动。它还是需要抓消息！

窗口的生命中枢：窗口函数

消息循环中的 DispatchMessage 把消息分配到哪里呢？它通过 USER 模块的协助，送到该窗口的窗口

函数去了。窗口函数通常利用 switch/case 方式判断消息种类，以决定处置方式。由于它是被 Windows 系

深入浅出 MFC

统所调用的（我们并没有在应用程序任何地方调用此函数），所以这是一种 call back 函数，意思是指「在

你的程序中，被 Windows 系统调用」的函数。这些函数虽然由你设计，但是永远不会也不该被你调用，

它们是为 Windows 系统准备的。

程序进行过程中，消息由输入装置，经由消息循环的抓取，源源传送给窗口并进而送到窗口函数去。

窗口函数的体积可能很庞大，也可能很精简，依该窗口感兴趣的消息数量多寡而定。至于窗口函数的型式，

相当一致，必然是：

LRESULT CALLBACK WndProc(HWND hWnd,

UINT message,

WPARAM wParam,

LPARAM lParam)

注意，不论什么消息，都必须被处理，所以 switch/case 指令中的 default: 处必须调用

DefWindowProc，这是 Windows 内部预设的消息处理函数。

窗口函数的 wParam 和 lParam 的意义，因消息之不同而异。wParam 在 16 位环境中是 16 位，在 32

位环境中是 32 位。因此，参数内容（格式）在不同作业环境中就有了变化。

我想很多人都会问这个问题：为什么 Windows Programming Modal 要把窗口函数设计为一个 call

back 函数？为什么不让程序在抓到消息（GetMessage）之后直接调用它就好了？原因是，除了你需要调

用它，有很多时候操作系统也要调用你的窗口函数（例如当某个消息产生或某个事件发生）。窗口函数设

计为 callback 形式，才能开放出一个接口给操作系统调用。

消息映射（Message Map）的雏形

有没有可能把窗口函数的内容设计得更模块化、更一般化些？下面是一种作法。请注意，以下作法是

MFC「消息映射表」（第９章）的雏形，我所采用的结构名称和变量名称，都与 MFC 相同，藉此让你先

有个暖身。

首先，定义一个 MSGMAP_ENTRY 结构和一个 dim 宏：

struct MSGMAP_ENTRY {

UINT nMessage;

LONG (*pfn)(HWND, UINT, WPARAM, LPARAM);

};

#define dim(x) (sizeof(x) / sizeof(x[0]))

请注意 MSGMAP_ENTRY 的第二元素 pfn 是一个函数指针，我准备以此指针所指之函数处理

nMessage 消息。这正是面向对象观念中把「数据」和「处理数据的方法」封装起来的一种具体实现，只

不过我们用的不是 C++语言。

接下来，组织两个数组_messageEntries[ ]和_commandEntries[ ]，把程序中欲处理的消息以及消息

处理例程的关联性建立起来：

// 消息与处理例程之对照表

struct MSGMAP_ENTRY _messageEntries[] =

{

WM_CREATE, OnCreate,

WM_PAINT, OnPaint,

WM_SIZE, OnSize,

WM_COMMAND, OnCommand,

WM_SETFOCUS, OnSetFocus,

WM_CLOSE, OnClose,

WM_DESTROY, OnDestroy,

}；这是消息这是消息处理例程

// Command-ID 与处理例程之对照表格

struct MSGMAP_ENTRY _commandEntries =

{

IDM_ABOUT, OnAbout,

IDM_FILEOPEN, OnFileOpen,

IDM_SAVEAS, OnSaveAs,

};这是 WM_COMMAND 命令项这是命令处理例程

于是窗口函数可以这么设计：

// 窗口函数

深入浅出 MFC

LRESULT CALLBACK WndProc(HWND hWnd, UINT message,

WPARAM wParam, LPARAM lParam)

{

int i;

for(i=0; i < dim(_messageEntries); i++) { // 消息对照表

if (message == _messageEntries[i].nMessage)

return((*_messageEntries[i].pfn)(hWnd,message,wParam,lParam))；

}

return(DefWindowProc(hWnd, message, wParam, lParam));

}

// OnCommand——专门处理 WM_COMMAND

LONG OnCommand(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)

{

int i;

for(i=0; i < dim(_commandEntries); i++) { // 命令项目对照表

if (LOWORD(wParam) == _commandEntries[i].nMessage)

return((*_commandEntries[i].pfn)(hWnd, message, wParam, lParam));

}

return(DefWindowProc(hWnd, message, wParam, lParam));

}

//----------------------------------------------------------------------

LONG OnCreate(HWND hWnd, UINT wMsg, UINT wParam, LONG lParam)

{

...

}

//----------------------------------------------------------------------

LONG OnAbout(HWND hWnd, UINT wMsg, UINT wParam, LONG lParam)

{

`...

}

这么一来，WndProc 和 OnCommand 永远不必改变，每有新要处理的消息，只要在_messageEntries[ ] 和

_commandEntries[ ] 两个数组中加上新元素，并针对新消息撰写新的处理例程即可。

这种观念以及作法就是 MFC 的 Message Map 的雏形。MFC 把其中的动作包装得更好更精致（当然因此

也就更复杂得多），成为一张庞大的消息地图；程序一旦获得消息，就可以按图上溯，直到被处理为止。

我将在第３章简单模拟 MFC 的 Message Map，并在第９章「消息映射与循环」中详细探索其完整内容。

对话框的运作

Windows 的对话框依其与父窗口的关系，分为两类：

1.「令其父窗口除能，直到对话框结束」，这种称为 modal 对话框。

2.「父窗口与对话框共同运行」，这种称为 modeless 对话框。

比较常用的是 modal 对话框。我就以 Generic 的 About 对话框做为说明范例。为了做出一个对话

框，程序员必须准备两样东西：

1. 对话框模板（dialog template）。这是在 RC 文件中定义的一个对话框外貌，以各种方式决定对

话框的大小、字形、内部有哪些控制组件、各在什么位置...等等。

2. 对话框函数（dialog procedure）。其类型非常类似窗口函数，但是它通常只处理 WM_INITDIALOG

和 WM_COMMAND 两个消息。对话框中的各个控制组件也都是小小窗口，各有自己的窗口函数，它们以消息

与其管理者（父窗口，也就是对话框）沟通。而所有的控制组件传来的消息都是 WM_COMMAND，再由其

参数分辨哪一种控制组件以及哪一种通告（notification）。

Modal 对话框的启动与结束，靠的是 DialogBox 和 EndDialog 两个 API 函数。请看图 1-4。

对话框处理过消息之后，应该传回 TRUE；如果未处理消息，则应该传回 FALSE。这是因为你的对话框

函数之上层还有一个系统提供的预设对话框函数。如果你传回 FALSE，该预设对话框函数就会接手处理。

模块定义文件（.DEF）

Windows 程序需要一个模块定义文件，将模块名称、程序节区和数据节区的内存特性、模块堆积

（heap）大小、堆栈（stack）大小、所有 callback 函数名称...等等登记下来。下面是个实例：

剩余429页未读，继续阅读

duanzw102

粉丝: 109
资源: 7

MFC入门指南：从Win32程序到C++特性与MFC应用

深入浅出MFC.pdf文挡

深入浅出ＭＦＣ．ｐｄｆ

深入浅出MFC.PDF(侯俊杰).繁体

深入浅出.MFC.pdf深入浅出.MFC.pdf3

工具变量城市供应链创新试点数据（2007-2023年）.xlsx

基于Python django-simpleui开发的博客系统详细文档+资料齐全.zip

嵌入式开发 操作系统教程 全部PPT课件 共8个章节.rar

基于Python Django教学资源管理系统网站+源码案例设计详细文档+资料齐全.zip

＜项目代码＞YOLOv8 建筑工地楼层空洞识别＜目标检测＞

【路径规划】未来搜索算法栅格地图机器人最短路径规划【含Matlab仿真 2868期】.zip

最新资源

嵌入式开发操作系统教程全部PPT课件共8个章节.rar