深入浅出MFC第2版(PDF格式)-第10部分
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
■ Top 范例程序（第15 章）：示范如何量身定做一个属于自己的AppWizard 。
我的这个Top Studio AppWizard 架在系统的MFC AppWizard 之上，增加一个
开发步骤，询问程序员名称及其简单声明，然后就会在每一个产生出来的原始
码文件最前端加上一段固定格式的说明文字。
■ Test 范例程序（第16 章）：此程序示范使用ponent Gallery 中的三
个ponents ：Splash Screen、SysInfo、Tip Of The Day 。
■ OcxTest 范例程序（第16 章）：此程序示范使用ponent Gallery 中的Grid
ActiveX control 。
38
…………………………………………………………Page 61……………………………………………………………
第０章 你定要知道（導讀）
与前版本之差异
深入浅出MFC 第二版与前一版本之重大差异在于：
1。 软件工具由Visual C＋＋ 4。0 改为Visual C＋＋ 5。0 ，影响所及，第４章「Visual C＋＋
整合性软件开发环境」之内容改变极大。全书之中有关于MFC 内部动作逻
辑及其源代码的变动不多，因为Visual C＋＋ 5。0 中的MFC 版本还维持在4。2 。
2。 第１章增加Console 程序设计，以及Win32 多线程程序实例Mltithrd 。
3。 第２章增加「四种不同的对象生存方式」一节。
4。 第３章去除原有之Frame5 程序（该程序以MFC 2。5 的技术仿真Dynamic
Creation ）。
5。 第４章全部改为Visual C＋＋ 5。0 使用画面，并在最后增加一节「Console 程序
的项目管理」。
6。 第６章增加「奇怪的窗口类别名称Afx：x：y：z：w 」一节，以及增加Hello 程序
对idle time 的处理。
7。 增加14~16 三章。
8。 附录Ａ增加 的「MFC 四大天王」一文。
9。 附录Ｄ由原先之「OWL 程序设计一览」，改为「以MFC 重建DBWIN 」。
本书第一版之Scribble 程序自step1 （加了CStroke）之后，即无法在Visual C＋＋ 4。2 和
Visual C＋＋ 5。0 上顺利编译。原因出在VC＋＋ 4。2 和VC＋＋ 5。0 似乎未能支持〃forward
declaration of data structure class〃 （但是我怀疑VC＋＋ 怎么会走退步？是不是有什么选项
可以设定）。无论如何，只要将CStroke 的声明搬移到SCRIBBLEDOC。H 的最前面，
然后再接续CScribbleDoc 的声明，即可顺利编译。请阅读本书第８章「CScribbleDoc 的
修改」一节之中于SCRIBBLEDOC。H 源代码列表后的一段说明（#477 页）。
39
…………………………………………………………Page 62……………………………………………………………
深入湷觥 FC
如何联络作者
我非常乐意和本书的所有读者沟通，接受您对本书以及对我的指正和建议。请将沟通内
容局限在对书籍、对知识的看法，以及对本书误谬之指正和建议上面，请勿要求我为您
解决技术问题（例如您的程序臭虫或您的项目瓶颈）。如果只是单纯地想和我交个朋友
聊聊天，我更倍感荣幸。
我的Email 地址是jjhou@ccca。nctu。edu。tw
我的永久通讯址是新竹市建中一路39 号13 楼之二（FAX ：03…5733976 ）
40
…………………………………………………………Page 63……………………………………………………………
1
勿在浮砂筑高台
深入湷觥FC
2nd Edition
1
…………………………………………………………Page 64……………………………………………………………
第篇 勿在浮砂築高台
2
…………………………………………………………Page 65……………………………………………………………
第 １章
Win32 基本程序观念
程序设计领域里，每一个人都想飞。
但是，还没学会走之前，连跑都别想！
虽然这是一本深入讲解MFC 程序设计的书，我仍坚持要安排这第一章，介绍Win32 的
基本程序设计原理（也就是所谓的SDK 程序设计原理）。
event driven message based
从来不曾学习过在「事件驱动（ ）系统」中撰写「以消息为基础（ ）
之应用程序」者，能否一步跨入MFC 领域，直接以application framework 开发Windows
MFC application framework
程序，我一直抱持怀疑的态度。虽然有了 （或任何其它的 ），
你可以继承一整组类别，从而快速得到一个颇具规模的程序，但是Windows 程序的运作
本质（Message Based，Event Driven ）从来不曾也不会改变。如果你不能了解其髓，空有
其皮其肉或其骨，是不可能有所精进的，即使能够操控wizard ，充其量却也只是个puppet ，
对于手上的程序代码，没有自主权。
我认为学习MFC 之前，必要的基础是，对于Windows 程序的事件驱动特性的了解（包
括消息的产生、获得、分派、判断、处理），以及对C＋＋ 多态（polymorphism ）的精确
体会。本章所提出的，是我对第一项必要基础的探讨，你可以从中获得关于Windows 程
序的诞生与死亡，以及多任务环境下程序之间共存的观念。至于第二项基础，将由第二章
为你夯实。
3
…………………………………………………………Page 66……………………………………………………………
让我再强调一遍，本章就是我认为Windows 程序设计者一定要知道的基础知识。一个
连这些基础都不清楚的人，不能要求自己冒冒然就开始用Visual C＋＋ 、用MFC、用对象
导向的方式去设计一个你根本就不懂其运作原理的程序。
还没学会走之前，不要跑！
Dialog Editor Image Editor Font Editor
。DLG 。BMP 。ICO 。CUR 。FON
。BMP 。ICO 。CUR 。FON
。C 。H 。RC RC piler
C piler 。RES
。RES
。DEF
CvtRes
。OBJ
。OBJ
tool RBJ
RBJ
。LIB
。LIB
text file
C runtime； 曾经有的程序，现已不需要
C runtime；
DLL Import； LINKER
DLL Import；
binary file 。EXE
。EXE
图 1…1 一个32位Windows SDK 程序的开发流程
4
…………………………………………………………Page 67……………………………………………………………
Win32 程序开发流程
Windows UI User Interface RC
程序分为「程序代码」和「 （ ）资源」两大部份，两部份最后以
EXE 图 UI
编译器整合为一个完整的 文件（ 1…1）。所谓 资源是指功能菜单、对话框
外貌、程序图标、光标形状等等东西。这些UI 资源的实际内容（二进制代码）系借助各
种工具产生，并以各种扩展名存在，如。ico、。bmp 、。cur 等等。程序员必须在一个所谓
。rc RC RC。EXE RC UI
的资源描述档（ ）中描述它们。 编译器（ ）读取 档的描述后将所有
资源档集中制作出一个。RES 档，再与程序代码结合在一起，这才是一个完整的Windows
可执行档。
。LIB
需要什么函数库 （ ）
众所周知Windows 支持动态联结。换句话说，应用程序所调用的Windows API 函数是
在「执行时期」才联结上的。那么，「联结时期」所需的函数库做什么用？有哪些？
并不是延伸档名为。dll 者才是动态联结函数库（DLL ，Dynamic Link Library ），事实
上。exe 、。dll、。fon、。mod、。drv、。ocx 都是所谓的动态联结函数库。
Windows C Runtimes Windows API C
程序调用的函数可分为 以及 两大部份。早期的
Runtimes 并不支持动态联结，但Visual C＋＋ 4。0 之后已支持，并且在32 位操作系统
中已不再有small/medium/large 等内存模式之分。以下是它们的命名规则与使用时机：
LIBC。LIB C Runtime
■ 这是 函数库的静态联结版本。
MSVCRT。LIB C Runtime MSVCRT40。DLL
■ 这是 函数库动态联结版本（ ）的
import 函数库。如果联结此一函数库，你的程序执行时必须有MSVCRT40。DLL
在场。
另一组函数，Windows API ，由操作系统本身（主要是Windows 三大模块GDI32。DLL 和
USER32。DLL 和KERNEL32。DLL ）提供（注）。虽说动态联结是在执行时期才发生「联
5
…………………………………………………………Page 68……………………………………………………………
结」事实，但在联结时期，联结器仍需先为调用者（应用程序本身）准备一些适当的信
息，才能够在执行时期顺利「跳」到DLL 执行。如果该API 所属之函数库尚未加载，
系统也才因此知道要先行加载该函数库。这些适当的信息放在所谓的「import 函数库」
中。32 位Windows 的三大模块所对应的import 函数库分别为GDI32。LIB 和USER32。LIB
和KERNEL32。LIB 。
注：谁都知道，Windows 95 是16/32 位的混合体，所以旗下除了32 位的GDI32。DLL 、
USER32。DLL KERNEL32。DLL 16 GDI。EXE USER。EXE
和 ， 又有 位的 、 和
KRNL386。EXE 。32 位和16 位两组DLLs 之间以所谓的thunking layer 沟通。站在纯
粹APIs 使用者的立场，目前我们不必太搭理这个事实。
Windows 发展至今，逐渐加上的一些新的API 函数（例如mon Dialog、ToolHelp ）
并不放在GDI 和USER 和KERNEL 三大模块中，而是放在诸如MDLG。DLL 、
TOOLHELP。DLL 之中。如果要使用这些APIs ，联结时还得加上这些DLLs 所对应的
import 函数库，诸如DLG32。LIB 和TH32。LIB 。
很快地，在稍后的范例程序！ §Generic！ ¨ 的makefile 中，你就可以清楚看到联结时期所需
的各式各样函数库（以及各种联结器选项）。
需要什么头文件 （ ）
