C++ 程序类型
答案:2 悬赏:30 手机版
解决时间 2021-11-14 19:48
- 提问者网友：却不属于对方
- 2021-11-14 12:27
C++ 程序类型
最佳答案
- 五星知识达人网友：七十二街
- 2021-11-14 14:02
Visual C++有能力创建你能够想像到（以及有些你想不到）的任何应用程序。然而，从整体上看，应用程序可以分为五种类型，这就是本文首先要集中讨论的内容：
1.控制台应用程序适用于你真正需要与遗留系统保持某种兼容性或不需要为用户提供全功能操作界面的情况。
2.基于对话框的应用程序通常是实用程序的专利，也适用于极小型不需要菜单系统的应用程序。
3.单文档应用程序适用于操作自有数据的简单应用程序，比如记事本或小型数据库前端应用。这类应用程序也需要某种类型的菜单系统。
4.多文档应用程序是提供完整功能的应用程序，比如字处理程序或电子表格。由于多文档应用程序是C++编程中十分复杂的部分，因此，当你考虑建立这类应用程序时，应该在Visual C++的灵活性与诸如Visual Basic之类的快速应用开发工具提供的速度之间进行权衡。
5.基于HTML的应用程序是Visual C++ 6.0新增的应用程序类型。它们操作某种类型的数据（像单文档或多文档应用程序那样），但与Internet结合在了一起。作为标准编辑器的替代物，你的用户会看到Web浏览器风格的前端应用。
注释 请注意本章我们在讨论应用程序。Visual C++有能力创建各种不同类型的代码。使用Visual C++不仅可以创建DLL、ActiveX控件、ISAPI扩展程序、设备驱动程序、像屏幕保护器之类的后台应用程序，甚至也可以扩展Visual C++本身。本章中我们只讨论一般的应用程序，随着本书的展开，我们也会介绍许多其它类型的代码。
控制台应用程序
我前面已经介绍过控制台应用程序的概况，但由于这一介绍过于粗略，以至于并未真正告诉读者控制台应用程序到底是什么样的。控制台应用程序具备DOS风格的窗口外观，而不是读者更熟悉一些的Windows风格窗口。控制台应用程序使用等距字体，就像你在DOS窗口中看到的那样，在控制台应用程序中可以使用标准C函数完成输入输出，比如printf和scanf()。然而，从内部上讲，控制台应用程序确实是个Windows应用程序。下图是个控制台应用程序的典型示例（本章后文中我们将实际创建一个这样的程序）。
注 使用控制台应用程序可以把某些功能型DOS代码转移到Windows系统之下。
那么，为什么要创建这种杂交怪物呢？假设说你有一些工作得很好的老的遗留代码，但它们是DOS下的应用程序。你想把这个程序迁移到Windows系统下，但又没有时间把所有代码都转换成Windows调用，那么控制台应用程序提供了一个折中的解决办法。在这类应用程序中你可以使用老的代码（至少是其中的一部分），但在Windows环境中执行这一程序。
注 从长远的观点看，创建控制台应用程序并不一定会节省时间和精力枣没有谁能保证让你使用所有现存代码。
使用控制台应用程序还有另外一个好处。当把应用程序从DOS搬到Windows中时，外观上就不一样。没有什么办法填平两者之间的鸿沟，从用户的观点来看，你引入了一个完全不同的应用程序，需要做出计划重新培训每一个工作人员及一切相关的事情。另一方面，控制台应用程序外观上与DOS应用程序十分相似，每个人都已经相当熟悉，因此或许你并不需要花多少精力进行配置。你会感到烦恼的唯一的一件事就是如何让每个人都习惯以不同方式运行应用程序。
然而，不要以为控制台应用程序是每个DOS应用程序迁移到Windows环境的理想途径。本质上两种方式下你都要创建新的应用程序，其间的唯一差别是可重用代码数量，因此也表现在创建新的应用程序所耗费的时间。事实上，如果你决定采用控制台应用程序这种方法时，只要考虑一下就会发现，你终将编写两个应用程序。绝大多数公司发现他们终将承受把DOS应用程序转换到Win-dows应用程序所付出的代价。
当然，如果DOS应用程序在DOS窗口中运行得相当好时，你也必须斟酌一下重新编写控制台应用程序是否明智。无疑地，控制台应用程序可以使用某些Windows服务，但或许所需的一切服务已经在DOS应用程序中实现了（你需要访问某些MFC函数以增强应用程序的功能并改进应用程序的易用性）。向你的DOS应用程序中添加越多的Windows功能，控制台应用程序的可采用性也变得越低。
可移植性 可以安全地假定使用控制台应用程序能够把DOS应用程序的“商务逻辑”迁移到Windows环境，也可以把某些显示和打印功能进行迁移。然而，想通过控制台应用程序使用一组代码同时实现DOS和Win-dows下应用程序的假定从来都不是安全的枣这两个环境的差别实在太大了，当把应用程序从DOS迁移到Windows时总需要进行某些修改。
基于对话框的应用程序
许多人把配置屏幕、About对话框之类的应用与基于对话框的应用程序联系起来，而把其它功能要求归类于全功能应用程序。基于对话框的应用程序在编程世界中也占有一席之地。它们对实用程序类应用程序极为有用，在这类应用程序中通常只需要显示少量的数据和获取少量的用户输入。下图是本章后面要创建的一个基于对话框的应用程序的示例：
技巧 当确定是创建基于对话框的应用程序还是创建基于窗口的应用程序时，需要考虑实用程序。如果你的应用程序适合作实用程序，那么基于对话框的应用程序界面或许是良好的选择。另一方面，如果打算在应用程序中添加众多的特性或者需要用户进行大量的交互操作，那么应该考虑选用基于窗口的界面。在做出决定时一定要考虑未来对应用程序的扩充问题枣今天做出的错误选择将在明天的重新实现中付出沉重的代价。
那么，到底是什么原因使基于对话框的应用程序比基于窗口的全功能应用程序更好呢？最重要的原因之一是程序规模。你可以创建同一个应用程序的两种版本，一种使用对话框界面，另一种使用窗口界面。每次做这样的实验时你都会发现对话框版本的程序更小一些。除了节省资源外，对话框版本的应用程序的加载速度也更快些。基于对话框的应用程序比完成相同功能的基于窗口的应用程序更简单有效。
你还会发现创建基于对话框的应用程序的速度也很快。基于对话框应用程序的特点就是规模小、效率高。当你发现需要在这类应用程序中增加大量功能和特性时，或许你一开始就选错了要创建的应用程序的类型。基于对话框的应用程序通常避免使用菜单和其它基于窗口应用程序为提供友好界面所需的部件。更少的特性减少了程序员的开发和调试时间。显然，任何有利于提高程序员效率的方法都值得一试。
注 把过多的控件塞进基于对话框的应用程序的做法只能使该应用程序既笨拙又难以使用。
基于对话框的应用程序并不一定要承受缺乏重要特性的遗憾。例如，你可以把基于对话框的应用程序创建成完美的OLE服务器。在这方面Visual C++向导会为你提供相应的帮助，因此，在应用程序中添加OLE支持只需要你多做一丁点工作。
使用对话框应用程序唯一存在的问题是某些程序员感到难以划分对话框。我曾经见过一个基于对话框的应用程序，其上充满了让人不知所措的各种小玩意。基于对话框的应用程序看上去会比同等功能的基于窗口的应用程序拥挤些，但也不应该把它们拥挤到谁也不能使用的地步。
技巧 就像Windows中用于配置的属性对话框那样，你可以使用选项卡来降低基于对话框应用程序界面的拥挤程度。
单文档界面应用程序
单文档界面应用程序是像NotePad（记事本）或Microsoft Paint（画笔）这样的应用程序。它一次处理一个文档，降低了编程的复杂度并减少了运行程序时所需的资源。对某些小型应用（比如文本编辑器或小型图像编辑器）可以采用这种类型的窗口应用程序。单文档界面应用程序允许用户与其创建的文档进行全面的交互，但通常不如多文档界面的应用程序耐用。另外，单文档界面应用程序至少要比多文档界面的应用程序少一个菜单枣就是用于选择要编辑文档的Windows菜单。
注 对只需要用户进行少量交互的小型应用程序来说，可以采用单文档、基于窗口的界面。
与基于对话框的应用程序相似，单文档应用程序也可以创建成OLE服务器。实际上，这类应用程序也可以作为OLE客户程序，尽管极少有程序员把这种能力添加到他的应用程序中。下图是本章后面要介绍的一个单文档应用程序示例。请注意这个示例可以作为OLE的客户端。
注 通过把应用程序的基视图类选择为CHtmlView，可以把单文档界面的应用程序转换成简单的Web浏览器。
不幸的是，单文档界面的应用程序与基于对话框的应用程序有相同的问题枣用起来太复杂了。我还记得以前使用老版本CorelDRAW时的问题。每当我想查看一幅图案时，不得不在查看之前首先关闭当前打开的文档。这种限制使得CorelDRAW比它应该提供的方法要难用一些。例如，我在比较两幅图案时浪费了太多的时间（所幸的是，Corel Systems在当前版本的CorelDRAW中已经纠正了这一缺陷）。
技巧 当操作数据库管理系统时，单文档、基于窗口的应用程序工作的相当完美，其原因相当简单，极少有用户需要同时打开多个数据库。即使他们需要同时打开多个数据库，数据库本身的使用规则也减少了用户本身访问多个数据库的可能性。正常情况下，你需要以可编程方式控制对各种数据库元素的访问，并把结果显示给用户。
多文档界面应用程序
现在我们来谈谈多文档界面应用程序。使用这种类型基于窗口的应用程序可以创建像字处理程序或电子表格那样的应用程序。例如，Microsoft Word和Microsoft Excel都是多文档应用程序的示例。如果你想一想，就会发现，文本编辑器具备有限吸引力的原因正是由于其一次只能打开一个文档。人们需要在文档之间进行比较，这就是多文档界面的应用程序不仅幽雅而且在众多情形下需要的原因。
注 通过把应用程序的基视图类选择为CHtmlView，可以把多文档界面的应用程序转换成简单的Web浏览器。
多文档界面的应用程序通常也都具有多种功能（你可能会走向另一个极端，看一看人们对当今厂商生产的主流产品臃肿特性的抱怨也就知道了）。文本编辑器可以提供十分简单的查找功能但并不提供替换文本的任何方法。而全功能的字处理程序则把查找和替换作为标准功能来对待。
多文档界面应用程序的缺点就在于它处理多个文档。同时处理多个文档的能力也意味着需要更多的额外编程工作。你并不只是要跟踪所有打开的文档，也要提供Windows菜单来管理特殊的程序特性，比如要考虑屏幕划分问题。你还需要决定是否允许用户同时显示多个文档。像最小化其中一个文档，而最大化另一个文档这样的任务也需要额外的程序代码。总而言之，即使在开始编写多文档应用程序之前，就需要做大量的编程准备工作了。
当然，多文档界面的应用程序也有不少的缺点。例如，如果你以前把Word用做过OLE服务器，你就会知道，在另一个应用程序中单击链接之后，每次打开这个庞大的应用程序时都要等待很长时间这种烦恼了。而且，你或许也经历过内存不够的困惑。在最近之前，每当你要使用OLE时，你就必须有足够的内存同时运行两个应用程序（客户和服务器）。所幸的是，通过让服务器接管客户端窗口的方法，Microsoft已经降低了这类内存需求，现在只负责操作文档本身了。客户窗口为服务器菜单和工具条提供了框架，因此不会再浪费额外的内存空间了。
基于HTML文档的应用程序
Visual C++ 6.0提供了一种新的应用程序类型，但你在New对话框的Project选项卡中却找不到它的踪影。你可以通过MFC AppWizard第6步的对话框创建基于HTML文档的应用程序，本章中我们将花费几节的篇幅讨论这方面的内容。上述对话框Base Class（基类）组合框中包含了一个CHtmlView选项，正是使用这个选项来创建这种新型的应用程序。
那么，基于HTML文档的应用程序有什么优点呢？想一想创建自己定制的Web浏览器的好处吧！你可以把这个浏览器设置成自动浏览公司Web站点并限制用户访问Web上非商务站点的方式。由于定制的浏览器不需要具备全功能浏览器所有的通用功能，因此，定制浏览器会减少内存需求和磁盘空间需求。换句话说，你可以建立一个提供浏览器所有功能、而又不存在它们所含问题的程序环境（至少在访问公司Web站点上是这样）。下图是个用于访问Web站点的基于HTML文档的应用程序的示例（显示的是CHtmlView类提供的缺省Web站点）。
不管怎么说，这种新型应用程序比你原先想像得更有价值。例如，你可以把CHtmlView类添加到现存应用程序中，让它能够访问基于Web服务器的帮助桌面（在第15章的“给你的应用程序添加基于HTML的帮助”一节我将介绍基于HTML的帮助）。作为创建标准帮助文件并把它添加到应用程序的一种替代方法，你可以创建十分专业化的Web浏览器，并把它置入到应用程序中。
基于HTML的帮助的优点十分明显。使用老的帮助文件就意味着一旦把应用程序交付给用户或在整个公司内分发后，你就不能够轻易地更新帮助文件。而更新HTML帮助则简单到只需要在Web服务器上修改文件即可。另外，使用Microsoft Help Workshop还需要做一些额外的工作。而基于HTML的帮助则既不需要编译器，也不需要特殊工具，只要有个文本编辑器即可（理论上说，在编写巨型帮助文件时，你需要个专门为操作HTML而设计的编辑器）。
HTML帮助也有一些缺陷。一方面，难以在基于HTML的帮助中建立能够满足需要的查询功能。由于查询用户所需的信息与建立这些信息处于同等重要的位置，因此，基于HTML的帮助并不适合于初级用户。另外，基于HTML的帮助必须建立Internet（至少为内部网）链接。如果你的公司中有许多旅途中的用户，那么试图建立Internet链接或许并不现实。当然，总可以复制所需的HTML文件，但这与以前的帮助形式存在相同的问题：过期的帮助文件。
这种新的应用程序类型还有许多其它的用途枣多的这里无法罗列。需要记住的重要一点是，从Internet访问中能够得到好处的应用程序从CHtmlView类的使用中也会得到好处。利用这个类，可以完成从销售代表处远程更新公司数据库到让用户易于登记产品之类的一切任务。换句话说，CHtmlView类为你和你的用户打开了一个新的世界。
1.控制台应用程序适用于你真正需要与遗留系统保持某种兼容性或不需要为用户提供全功能操作界面的情况。
2.基于对话框的应用程序通常是实用程序的专利，也适用于极小型不需要菜单系统的应用程序。
3.单文档应用程序适用于操作自有数据的简单应用程序，比如记事本或小型数据库前端应用。这类应用程序也需要某种类型的菜单系统。
4.多文档应用程序是提供完整功能的应用程序，比如字处理程序或电子表格。由于多文档应用程序是C++编程中十分复杂的部分，因此，当你考虑建立这类应用程序时，应该在Visual C++的灵活性与诸如Visual Basic之类的快速应用开发工具提供的速度之间进行权衡。
5.基于HTML的应用程序是Visual C++ 6.0新增的应用程序类型。它们操作某种类型的数据（像单文档或多文档应用程序那样），但与Internet结合在了一起。作为标准编辑器的替代物，你的用户会看到Web浏览器风格的前端应用。
注释 请注意本章我们在讨论应用程序。Visual C++有能力创建各种不同类型的代码。使用Visual C++不仅可以创建DLL、ActiveX控件、ISAPI扩展程序、设备驱动程序、像屏幕保护器之类的后台应用程序，甚至也可以扩展Visual C++本身。本章中我们只讨论一般的应用程序，随着本书的展开，我们也会介绍许多其它类型的代码。
控制台应用程序
我前面已经介绍过控制台应用程序的概况，但由于这一介绍过于粗略，以至于并未真正告诉读者控制台应用程序到底是什么样的。控制台应用程序具备DOS风格的窗口外观，而不是读者更熟悉一些的Windows风格窗口。控制台应用程序使用等距字体，就像你在DOS窗口中看到的那样，在控制台应用程序中可以使用标准C函数完成输入输出，比如printf和scanf()。然而，从内部上讲，控制台应用程序确实是个Windows应用程序。下图是个控制台应用程序的典型示例（本章后文中我们将实际创建一个这样的程序）。
注 使用控制台应用程序可以把某些功能型DOS代码转移到Windows系统之下。
那么，为什么要创建这种杂交怪物呢？假设说你有一些工作得很好的老的遗留代码，但它们是DOS下的应用程序。你想把这个程序迁移到Windows系统下，但又没有时间把所有代码都转换成Windows调用，那么控制台应用程序提供了一个折中的解决办法。在这类应用程序中你可以使用老的代码（至少是其中的一部分），但在Windows环境中执行这一程序。
注 从长远的观点看，创建控制台应用程序并不一定会节省时间和精力枣没有谁能保证让你使用所有现存代码。
使用控制台应用程序还有另外一个好处。当把应用程序从DOS搬到Windows中时，外观上就不一样。没有什么办法填平两者之间的鸿沟，从用户的观点来看，你引入了一个完全不同的应用程序，需要做出计划重新培训每一个工作人员及一切相关的事情。另一方面，控制台应用程序外观上与DOS应用程序十分相似，每个人都已经相当熟悉，因此或许你并不需要花多少精力进行配置。你会感到烦恼的唯一的一件事就是如何让每个人都习惯以不同方式运行应用程序。
然而，不要以为控制台应用程序是每个DOS应用程序迁移到Windows环境的理想途径。本质上两种方式下你都要创建新的应用程序，其间的唯一差别是可重用代码数量，因此也表现在创建新的应用程序所耗费的时间。事实上，如果你决定采用控制台应用程序这种方法时，只要考虑一下就会发现，你终将编写两个应用程序。绝大多数公司发现他们终将承受把DOS应用程序转换到Win-dows应用程序所付出的代价。
当然，如果DOS应用程序在DOS窗口中运行得相当好时，你也必须斟酌一下重新编写控制台应用程序是否明智。无疑地，控制台应用程序可以使用某些Windows服务，但或许所需的一切服务已经在DOS应用程序中实现了（你需要访问某些MFC函数以增强应用程序的功能并改进应用程序的易用性）。向你的DOS应用程序中添加越多的Windows功能，控制台应用程序的可采用性也变得越低。
可移植性 可以安全地假定使用控制台应用程序能够把DOS应用程序的“商务逻辑”迁移到Windows环境，也可以把某些显示和打印功能进行迁移。然而，想通过控制台应用程序使用一组代码同时实现DOS和Win-dows下应用程序的假定从来都不是安全的枣这两个环境的差别实在太大了，当把应用程序从DOS迁移到Windows时总需要进行某些修改。
基于对话框的应用程序
许多人把配置屏幕、About对话框之类的应用与基于对话框的应用程序联系起来，而把其它功能要求归类于全功能应用程序。基于对话框的应用程序在编程世界中也占有一席之地。它们对实用程序类应用程序极为有用，在这类应用程序中通常只需要显示少量的数据和获取少量的用户输入。下图是本章后面要创建的一个基于对话框的应用程序的示例：
技巧 当确定是创建基于对话框的应用程序还是创建基于窗口的应用程序时，需要考虑实用程序。如果你的应用程序适合作实用程序，那么基于对话框的应用程序界面或许是良好的选择。另一方面，如果打算在应用程序中添加众多的特性或者需要用户进行大量的交互操作，那么应该考虑选用基于窗口的界面。在做出决定时一定要考虑未来对应用程序的扩充问题枣今天做出的错误选择将在明天的重新实现中付出沉重的代价。
那么，到底是什么原因使基于对话框的应用程序比基于窗口的全功能应用程序更好呢？最重要的原因之一是程序规模。你可以创建同一个应用程序的两种版本，一种使用对话框界面，另一种使用窗口界面。每次做这样的实验时你都会发现对话框版本的程序更小一些。除了节省资源外，对话框版本的应用程序的加载速度也更快些。基于对话框的应用程序比完成相同功能的基于窗口的应用程序更简单有效。
你还会发现创建基于对话框的应用程序的速度也很快。基于对话框应用程序的特点就是规模小、效率高。当你发现需要在这类应用程序中增加大量功能和特性时，或许你一开始就选错了要创建的应用程序的类型。基于对话框的应用程序通常避免使用菜单和其它基于窗口应用程序为提供友好界面所需的部件。更少的特性减少了程序员的开发和调试时间。显然，任何有利于提高程序员效率的方法都值得一试。
注 把过多的控件塞进基于对话框的应用程序的做法只能使该应用程序既笨拙又难以使用。
基于对话框的应用程序并不一定要承受缺乏重要特性的遗憾。例如，你可以把基于对话框的应用程序创建成完美的OLE服务器。在这方面Visual C++向导会为你提供相应的帮助，因此，在应用程序中添加OLE支持只需要你多做一丁点工作。
使用对话框应用程序唯一存在的问题是某些程序员感到难以划分对话框。我曾经见过一个基于对话框的应用程序，其上充满了让人不知所措的各种小玩意。基于对话框的应用程序看上去会比同等功能的基于窗口的应用程序拥挤些，但也不应该把它们拥挤到谁也不能使用的地步。
技巧 就像Windows中用于配置的属性对话框那样，你可以使用选项卡来降低基于对话框应用程序界面的拥挤程度。
单文档界面应用程序
单文档界面应用程序是像NotePad（记事本）或Microsoft Paint（画笔）这样的应用程序。它一次处理一个文档，降低了编程的复杂度并减少了运行程序时所需的资源。对某些小型应用（比如文本编辑器或小型图像编辑器）可以采用这种类型的窗口应用程序。单文档界面应用程序允许用户与其创建的文档进行全面的交互，但通常不如多文档界面的应用程序耐用。另外，单文档界面应用程序至少要比多文档界面的应用程序少一个菜单枣就是用于选择要编辑文档的Windows菜单。
注 对只需要用户进行少量交互的小型应用程序来说，可以采用单文档、基于窗口的界面。
与基于对话框的应用程序相似，单文档应用程序也可以创建成OLE服务器。实际上，这类应用程序也可以作为OLE客户程序，尽管极少有程序员把这种能力添加到他的应用程序中。下图是本章后面要介绍的一个单文档应用程序示例。请注意这个示例可以作为OLE的客户端。
注 通过把应用程序的基视图类选择为CHtmlView，可以把单文档界面的应用程序转换成简单的Web浏览器。
不幸的是，单文档界面的应用程序与基于对话框的应用程序有相同的问题枣用起来太复杂了。我还记得以前使用老版本CorelDRAW时的问题。每当我想查看一幅图案时，不得不在查看之前首先关闭当前打开的文档。这种限制使得CorelDRAW比它应该提供的方法要难用一些。例如，我在比较两幅图案时浪费了太多的时间（所幸的是，Corel Systems在当前版本的CorelDRAW中已经纠正了这一缺陷）。
技巧 当操作数据库管理系统时，单文档、基于窗口的应用程序工作的相当完美，其原因相当简单，极少有用户需要同时打开多个数据库。即使他们需要同时打开多个数据库，数据库本身的使用规则也减少了用户本身访问多个数据库的可能性。正常情况下，你需要以可编程方式控制对各种数据库元素的访问，并把结果显示给用户。
多文档界面应用程序
现在我们来谈谈多文档界面应用程序。使用这种类型基于窗口的应用程序可以创建像字处理程序或电子表格那样的应用程序。例如，Microsoft Word和Microsoft Excel都是多文档应用程序的示例。如果你想一想，就会发现，文本编辑器具备有限吸引力的原因正是由于其一次只能打开一个文档。人们需要在文档之间进行比较，这就是多文档界面的应用程序不仅幽雅而且在众多情形下需要的原因。
注 通过把应用程序的基视图类选择为CHtmlView，可以把多文档界面的应用程序转换成简单的Web浏览器。
多文档界面的应用程序通常也都具有多种功能（你可能会走向另一个极端，看一看人们对当今厂商生产的主流产品臃肿特性的抱怨也就知道了）。文本编辑器可以提供十分简单的查找功能但并不提供替换文本的任何方法。而全功能的字处理程序则把查找和替换作为标准功能来对待。
多文档界面应用程序的缺点就在于它处理多个文档。同时处理多个文档的能力也意味着需要更多的额外编程工作。你并不只是要跟踪所有打开的文档，也要提供Windows菜单来管理特殊的程序特性，比如要考虑屏幕划分问题。你还需要决定是否允许用户同时显示多个文档。像最小化其中一个文档，而最大化另一个文档这样的任务也需要额外的程序代码。总而言之，即使在开始编写多文档应用程序之前，就需要做大量的编程准备工作了。
当然，多文档界面的应用程序也有不少的缺点。例如，如果你以前把Word用做过OLE服务器，你就会知道，在另一个应用程序中单击链接之后，每次打开这个庞大的应用程序时都要等待很长时间这种烦恼了。而且，你或许也经历过内存不够的困惑。在最近之前，每当你要使用OLE时，你就必须有足够的内存同时运行两个应用程序（客户和服务器）。所幸的是，通过让服务器接管客户端窗口的方法，Microsoft已经降低了这类内存需求，现在只负责操作文档本身了。客户窗口为服务器菜单和工具条提供了框架，因此不会再浪费额外的内存空间了。
基于HTML文档的应用程序
Visual C++ 6.0提供了一种新的应用程序类型，但你在New对话框的Project选项卡中却找不到它的踪影。你可以通过MFC AppWizard第6步的对话框创建基于HTML文档的应用程序，本章中我们将花费几节的篇幅讨论这方面的内容。上述对话框Base Class（基类）组合框中包含了一个CHtmlView选项，正是使用这个选项来创建这种新型的应用程序。
那么，基于HTML文档的应用程序有什么优点呢？想一想创建自己定制的Web浏览器的好处吧！你可以把这个浏览器设置成自动浏览公司Web站点并限制用户访问Web上非商务站点的方式。由于定制的浏览器不需要具备全功能浏览器所有的通用功能，因此，定制浏览器会减少内存需求和磁盘空间需求。换句话说，你可以建立一个提供浏览器所有功能、而又不存在它们所含问题的程序环境（至少在访问公司Web站点上是这样）。下图是个用于访问Web站点的基于HTML文档的应用程序的示例（显示的是CHtmlView类提供的缺省Web站点）。
不管怎么说，这种新型应用程序比你原先想像得更有价值。例如，你可以把CHtmlView类添加到现存应用程序中，让它能够访问基于Web服务器的帮助桌面（在第15章的“给你的应用程序添加基于HTML的帮助”一节我将介绍基于HTML的帮助）。作为创建标准帮助文件并把它添加到应用程序的一种替代方法，你可以创建十分专业化的Web浏览器，并把它置入到应用程序中。
基于HTML的帮助的优点十分明显。使用老的帮助文件就意味着一旦把应用程序交付给用户或在整个公司内分发后，你就不能够轻易地更新帮助文件。而更新HTML帮助则简单到只需要在Web服务器上修改文件即可。另外，使用Microsoft Help Workshop还需要做一些额外的工作。而基于HTML的帮助则既不需要编译器，也不需要特殊工具，只要有个文本编辑器即可（理论上说，在编写巨型帮助文件时，你需要个专门为操作HTML而设计的编辑器）。
HTML帮助也有一些缺陷。一方面，难以在基于HTML的帮助中建立能够满足需要的查询功能。由于查询用户所需的信息与建立这些信息处于同等重要的位置，因此，基于HTML的帮助并不适合于初级用户。另外，基于HTML的帮助必须建立Internet（至少为内部网）链接。如果你的公司中有许多旅途中的用户，那么试图建立Internet链接或许并不现实。当然，总可以复制所需的HTML文件，但这与以前的帮助形式存在相同的问题：过期的帮助文件。
这种新的应用程序类型还有许多其它的用途枣多的这里无法罗列。需要记住的重要一点是，从Internet访问中能够得到好处的应用程序从CHtmlView类的使用中也会得到好处。利用这个类，可以完成从销售代表处远程更新公司数据库到让用户易于登记产品之类的一切任务。换句话说，CHtmlView类为你和你的用户打开了一个新的世界。
全部回答
- 1楼网友：山君与见山
- 2021-11-14 14:19
循环结构，顺序结构，选择结构
我要举报
如以上回答内容为低俗、色情、不良、暴力、侵权、涉及违法等信息，可以点下面链接进行举报！
点此我要举报以上问答信息
大家都在看
推荐资讯