[摘要]：目前在Windows下开发应用程序的工具虽然很多，但是C/C++作为一种非常成熟和高效的开发语言在大型复杂项目的开发中仍然得到了广泛应用。
为了减轻程序开发负担，提高开发效率，各种流行的C++都提供了类库，本文就是针对如何在Visual C++环境中使用MFC类库来开发高级程序所需要解决的一些问题进行了的探讨，重点讨论了利用MFC开发单文档多视应用程序和DDE应用程序的方法。
一、使用C/C++
随着Windows系列操作系统的日益普遍，传统的基于DOS编程逐渐转向Windows下编程已经成为必然趋势。目前在Windows下开发应用程序的工具很多，典型的如Borland C++、Visual C++、Visual Baisic以及Delphi等等。每种开发工具都各有其特点，一般来讲用户可以根据自己的使用习惯和开发项目的性质来选择具体的开发语言。
Visual Basic是一个被软件界称之为划时代的革新产品，该软件改变了人们开发Windows程序的方式，它采用交互式的可视化操作，使得人们开发Windows程序的每一过程都有直观形象的反馈，从而加速整个开发进程。Visual Basic使得Windows程序设计人员不再只依赖于复杂的SDK编程，使得开发Windows程序非常容易，可以说，用户学习并使用VB来开发Windows应用的时间是最短的。Visual Basic版本几经演变，目前已经发展到5.0。在4.0版本中，由于完全使用了面向对象的编程概念，同时具有Windows 3.1和Windows 95下的版本，因而使得其开发复杂程序的功能逐渐增强。VB5.0则抛弃了Windows 3.x的用户，只能在32位Windows中使用，据悉，该版本吸收了Delphi的成功策略，引入了本地代码(Native Code)编译器，从而使得程序执行速度大大加快，克服了以往版本由于执行文件采用P-Code代码而导致运行速度慢的特点，根据微软的声明，该版本的采用本地代码编译后得到的应用程序在某些情况下执行速度较以往提高了10~20倍，执行速度可以直逼与采用Visual C++编写的应用，而应用开发速度则是VB的强项，因此Visual Basic 5.0非常具有竞争性。目前Visual Basic非常广泛地用于开发各种Windows程序，如数据库前端应用程序和多媒体应用等。但是，在作者看来，采用VB也有一定的缺点，原因有以下几点：
1. Visual Basic来源于Basic语言，虽然经过微软的不断增强，但是仍然缺乏非常灵活的数据类型和编程策略，因而在开发一些项目必须的复杂数据结构遇到麻烦，如链表、图和二叉树等等。由于在中大型项目开发后期，开发工作不再以界面为主，而是在算法设计和底层软硬件工作，这就使VB开发项目的后期工作量大幅度增加，为了达到项目要求，经常需要再转向C/C++开发一些专用的动态连接库来解决问题。
2. Visual Basic运行速度慢，前文讲过，采用P-Code代码虽然执行文件很小，但是在运行时需要解释执行，并且，它的运行必须有对应的VBRUN.DLL和所使用的VBX或者OCX支持。对于浮点操作密集或者循环嵌套很多的应用来说，VB没有采取特别的优化，因而执行速度远不如用C/C++和Fortran开发的应用速度快。VB 5.0虽然通过引入本地代码编译器大大弥补了这个缺陷，但是由于其只能运行于32位Windows环境因而在16位Windows上速度问题仍然得不到解决。虽然目前转向32位Windows的趋势非常强劲，但是不容忽视由于硬件的限制或者使用习惯等诸多原因，还有许多用户仍然在16位Windows上工作。在计算机十分普及的美国，96年使用16位Windows的用户仍然超过了使用32位Windows的用户，任何进行系统软件设计的人员都应该照顾到这些仍然使用16位Windows的用户。
3. VB不能灵活地使用系统资源。熟悉Windows编程的人都知道，如果要直接访问硬件或者要编写对系统进行有效访问的应用程序，没有Windows API函数的帮助则非常困难，但是令VB程序员失望的是，API函数是用C语言和汇编语言实现的，是为C编程准备的，如果要在VB里面使用这些上千个API函数则比较麻烦，特别是，如果设计人员不懂C语言则尤其困难。由于API函数的复杂性，而其本身不是为了方便VB编程而提供的，因此在VB里面调用API函数需要一定的技巧，这些技巧足够用一本很厚的书来表述。VB程序员可以从书店里找到好多本类似的书籍。可以说，任何一个VB程序员发展到一定阶段都需要与众多的API函数打交道。另外，由于VB不支持端口操作，因此，如果要编写类似数据采集等需要与硬件交互的程序则需要求救于C/C++语言。
4. Visual Basic项目分发和管理困难，其原因同上讲的，VB应用的运行不能脱离VB的运行库和所使用的控件，因此，如果开发人员要将VB应用分发给用户那么一定要带上VB的运行库和所使用的控件，并且要保证正确安装，这就导致即使一个非常简单的应用也需要附带大量其它相关支撑库程序，对于VB 4.0及更高版本，由于大量的使用了OLE控件（在VB中称为OCX），其安装更为复杂。
Delphi软件是国际宝兰公司(Borland)的得意之作，也是备受软件界推崇，与VB一样，它完全是一个交互式的可视化开发平台，支持Client/Server应用程序的开发，其最新版本2.0可以开发Windows 3.x、Windows 95和Windows NT的应用程序。Delphi开发速度也非常快，与VB相比，由于具有本地代码编译器因此它产生的可执行文件执行速度大大加快。Delphi软件是一个非常有竞争力的软件，采用的是面向对象的Object pascal语言，支持硬件操作和API调用。但是由于采用的编程语言为Pascal，这种语言并不非常流行，许多程序设计人员完全不熟悉这种语言，因此极大地限制了该软件的使用，如果宝兰公司能够将Delphi软件提供的RAD开发机制引入到其Borland C++中，则可能会形成一个非常成功的产品（目前该版本已经推出，即C++ Builder，笔者注）。
VB和Delphi引入的可视化开发方法还有一个共同的缺点就是各个版本之间的兼容问题。一般来讲，采用这些可视化开发工具开发的应用程序在移植到高版本时不会遇到太大困难，但是一旦往相反方向移植则困难重重，有时甚至不可能。C/C++语言则不具有这种局限性，各个版本之间的相互移植并不困难，高版本往低版本移植一般只需重建工程文件即可大功告成。
综上所述，根据作者的观点，如果要开发一个大型复杂的应用程序首选的还是C/C++，特别是在16位Windows下。虽然这会使前期工作增加，但是在项目的中后期将逐渐会领略到其优越性和开发效率，其灵活高效的执行代码适合于对速度和应用程序之间的协同性要求很高的场合。纯粹基于Windows SDK来开发Windows程序是一项艰巨的工程，值得庆幸的是目前各种流行的C/C++开发工具都提供了类库开发框架来简化整个开发过程而又不失其固有的灵活高效性，不同的开发语言所提供的类库开发框架不同，如Borland C++提供的OWL(Object Windows Library)和 Visual C++提供的MFC(Microsoft Fundmental Class)，这两种类库都封装了大量的Windows API和Windows的开发元素而使得开发任务简化，两种类库各有其优点，据作者掌握的资料，采用MFC编写的应用程序执行代码更小，执行速度也更快，这大概是因为该软件的开发者是开发Windows操作系统的Microsoft公司的缘故吧，现在MFC正逐渐成为Windows下的类库开发标准，正被越来越多的其它C/C++编译工具所支持，如Watcom C++。使用MC类库同时配合Visual C++提供的AppWizard、ClassWizard和AppStudio可以大幅度提高开发效率。笔者在工作中积累了一些MFC的使用经验现在提出来供大家参考，希望对广大同行有所帮助，尤其是那些仍然致力于16位Windows编程的程序员。本文使用的Visual C++ 1.51编译器，但是其方法同样适用于其它VC++版本，包括Visual C++ 4.x。
二、MFC编程综述
采用MFC开发Windows程序之所以能够大幅度提高开发速度和效率主要是因为MFC在类层次封装了大量Windows SDK函数和典型Windows应用的缺省处理，这样，用户只需要较少的编程就可以实现自己的开发任务。如果在MFC基础上再配合Visual C++提供的AppWizard、ClassWizard和AppStudio工具那么更可以大幅度加快开发进程。MFC提供大量的基类供程序员使用，常见的如CWinApp类、CFrameWnd类、CMDIFrameWnd类、CMDIChildWnd类、CView类、CDC类和CDocument类等等。通过从这些基类中派生出用户自己的类，然后重载特殊的几个函数就可以生成一个独立的应用程序。可以说，采用MFC编写Windows应用程序是非常方便的，虽然其学习过程并不简单，但是其提供的灵活高效性足以使任何Windows程序开发人员为之付出努力。如果用户不曾使用过MFC，那么用户可以通过附录中所列的参考书去学习MFC的强大功能。
采用MFC应用框架产生的应用程序使用了标准化的结构，因而使得采用MFC编写的程序的在不同平台上的移植变得非常容易，事实上，MFC的16位和32位版本之间差别很小。MFC提供的标准化结构是经过众多专家分析调研后总结编写出来的，一般情况下可以满足绝大多数用户的要求，但有时用户也可以通过重载一些函数来修改其缺省的风格从而实现自己特有的风格，如自定义应用图表和灰色背景等。在MFC提供的文档视结构中，文档、视和资源之间的联系是通过定义文档模板来实现的，如：
m_pSimuTemplate = new CMultiDocTemplate(
IDR_SIMUTYPE,
RUNTIME_CLASS(CSimuDoc),
RUNTIME_CLASS(CMyChild), // Derived MDI child frame
RUNTIME_CLASS(CSimuView));
上中第一项IDR_SIMUTYPE就包括了视口的菜单，加速键和图表等资源，如果用户使用AppWizard来产生的应用基本框架，那么其也同时产生了缺省的图标，如果用户不满意缺省图标（实际上用户很少满足于缺省图标），只需要将缺省图标删除，然后编辑或者直接引入一个新的图标，在存储这一图标时只需要使用与被删除图标同样的ID即可实现替代。
熟悉Windows程序开发的人都知道，在Windows上通过使用灰色背景可以增强应用程序的视觉效果，曾有人戏称，灰色是图形界面永恒的颜色。使用MFC产生的应用程序的背景缺省为白色，如果用户希望改变成灰色或者其它颜色，那就需要使用单独处理，解决的办法很多，如在每次视口的OnPaint()事件中采用灰色刷子人为填充背景，但是这不是最好的办法。笔者发现最好的办法就是采用AfxRegisterWndClass()函数注册一个使用灰色背景刷的新的窗口类，这需要重载PreCreateWindow()函数来实现这一点，如下程序代码片段所示：
BOOL CSimuView::PreCreateWindow(CREATESTRUCT& cs)
{
HBRUSH hbkbrush=CreateSolidBrush(RGB(192,192,192));//创建灰色背景刷
LPCSTR lpMyOwnClass=AfxRegisterWndClass(CS_HREDRAW | CS_VREDRAW|CS_OWNDC,0,hbkbrush);//注册新类
cs.lpszClass=lpMyOwnClass;//修改缺省的类风格
return TRUE;
}
采用这种方法速度最快，也最省力。同时，还可以在PreCreateWindow()函数定义所希望的任何窗口风格，如窗口大小，光标式样等。
三、使用单文档-多视结构
如果用户使用过MFC进行编程，那么就会发现借助于AppWizard基于MFC无论编写SDI(单文档界面)还是编写MDI(多文档界面)都是十分方便的。MDI应用程序目前使用越来越普遍，人们熟悉的Microsoft公司的Office系列产品以及Visual系列产品都是典型的多文档应用程序。这种多文档界面具有多窗口的特点，因而人们可以在一个程序中使用多个子窗口来实现不同数据的浏览查看。如果用户要实现在MDI各个窗口之间针对同一数据进行不同的可视化就是一件比较麻烦的事情。值得庆幸的是，MFC提供的文档-视结构大大简化了这一工作。文档-视结构通过将数据从用户对数据的观察中分离出来，从而方便实现多视，亦即多个视口针对同一数据，如果一个视口中数据发生改变，那么其它相关视口中的内容也会随之发生改变以反映数据的变化。
SDI和MDI这两种Windows标准应用程序框架并不是总能满足用户的需要，就作者的工作而言，就特别需要一种被称为单文档多视的应用程序，英文可以缩写为SDMV。通过SDMV应用我们可以利用文档类来统一管理应用程序的所有数据，同时需要采用多窗口以多种方式来可视化这些的数据，如棒图，趋势图和参数列表，从而方便用户从不同角度来观察数据。MDI虽然具有多窗口的特点，但是其为多文档，即通常情况下，一个视口对应一个文档，视口+文档便构成一个子窗口。在各个子窗口之间数据相互独立，如果要保持数据同步更新就需要采用特殊的技术了，采用这种方式既费时又费力。通过笔者的实践发现，利用MFC本身提供的多视概念通过适当改造MDI窗口应用程序就可以实现上述SDMV结构。
所谓SDMV应用程序本质上仍然是一个MDI应用程序，只是在程序中我们人为控制使其只能生成一个文档类，这个文档在第一个视口创建时创建，注意，这里并不需要限制各个视口的创建先后顺序。此后与MDI窗口固有特性不同的是，所有新创建的子窗口都不再创建独立文档，而是把该新视口直接连接到已有的文档对象上，这样就使其成为单文档多视的结构，所有相关数据都存储在文档对象中，一旦文挡中数据发生改变，通过UpdateAllViews()函数通知所有相关视口，各个视口就可以在OnUpdate()中相应数据的变化。这种响应机制如下图所示:
由于MDI本质上并不是为这种单文档多视机制服务的，因而在实际应用时需要解决一些问题。
