第18章_创建Windows程序

第18章创建Windows程序第18章将对已经介绍过的技术进行巩固，并示范如何使用这些技术来开发实际的程序。

本章中的第一个程序是Rich Text编辑器。

之所以选择这个例子，是因为在第14章中您已经熟悉了RichEdit控件；这里将着重强调Delphi为开发Windows程序所提供的各种支持。

本章中的应用程序并不难于开发，但却足以用于讨论应用程序开发的许多方面。

而且Delphi 6引入了TAction组件，可以有效地减少所需编写代码的数量。

由于前面的章节并未涵盖TActionList和TAction组件，本章将介绍这两个新的组件。

另外，在示例程序中使用了MDI（多文档界面），前面的章节也没有涉及到。

为演示如何建立RichEditor.exe例子程序，我们在本章中将涵盖如下内容：分析与设计、工程的准备工作、MDI的使用、Windows注册表的管理、添加帮助文档，以及部署程序的准备工作。

读完本章后，您可以全面了解Delphi所提供的工具，以及一些可用于支持开发具有专业水准应用程序的工具。

18.1 准备工作工程的准备工作有许多种形式。

如果要建立原型，那么只要启动Delphi并了解要建立什么原型即可。

在开发不太复杂的应用程序时，如本章中的例子，对工作进行一下综述也就足够了。

如果开发的应用程序只供自己使用，可以跳过这一步。

如果程序是供内部合作使用或为客户开发的，那么对工作陈述一下也就可以了。

比本章中的RichEditor更为复杂的程序，都至少需要进行文档化的、正式的分析与设计。

不幸的是，事实刚好相反。

许多程序都只是由管理者和程序员开发的，其中缺少一些必要的角色，如体系结构设计师、分析人员、设计人员、产品经理、工程经理、测试人员、质量保证负责人、文档专家、工具建立者、以及库管理人员。

想像一下，如果航班没有行李管理人员、旅行代理人、售票代理人、保安人员、飞行员、副驾驶员、领航员、以及服务人员，那会出现什么样的混乱。

当开发复杂软件时，每个人可能会担任多个角色，但是像体系结构设计师和工程经理这样的角色，其责任实在重大，所以要确保每个这样的角色至少由一个人来担任。

对于体系结构设计师来说，由一个人建立的单一而一致的概念化模型可能是最好的。

程序员开发RichEditor程序的复杂程度，与飞行员驾驶单引擎小飞机相似。

大多数情况下，一个单人小组即可完成工作。

但是要谨慎，组织和计划即使对于第18章创建Windows程序单人小组也是很重要的。

对于我们的简单例子程序，单个人就能够担任所有的角色。

对工作进行一下陈述也就足够了。

可以把工作描述为：“实现文本编辑器，能够同时读写多个Rich Text或DOS Text格式的文档。

”注意：如果您所在的工程不只一个人，那么使用版本控制产品并形成一致的目录结构是很重要的，这样可以有效地减少协作者之间的问题，还可以加快新人融入到团队的转变过程。

随着时间过去，任何可以减轻工作负担的措施都会得到回报，即使非常简单的应用程序也是如此。

　对于我们的简单程序来说，最后一点就是要组装有用的目录结构，并实现版本控制机制。

基本的目录结构对于工程的组装是很有帮助的。

18.1.1 大有帮助的简单工作当与其他开发者一同工作时，或同时开发多个工程时，基本的目录结构可以有效地减少迷惑。

RichEditor的目录结构以目录树的形式如下列出。

-RichEditor-Bin-Documents-Help-Output-Source-VCL当然，您可以使用任何目录结构，只要适合需求即可。

但选定一种目录结构并保证一致的使用，可以减少源代码文件的混乱，而且Delphi还支持在多个目录进行不同的输出。

Bin目录在RichEditor工程中用于编译过的可执行文件，本例中RichEditor.exe在编译后将写入到Bin子目录。

Output目录用于存储编译过的单元，即.DCU文件，将其与源文件隔离开来。

源代码文件将存储在Source子目录中。

18.1.2 版本控制版本控制机制会跟踪源代码相对于时间的演化。

您可以将单独的文件或整个的应用程序回复到以前的版本。

有些产品还可以将缺陷与源代码关联起来，维护问题出现和解决时的线程信息。

如果没有版本控制程序，您可以买一个。

有许多可以选择的产品。

高端产品包括Harvest、Clearcase和PVCS。

低端和中级产品包括SourceSafe和StarTeam。

所有这些产品都提供了基本的能力，可以将您的工作随时间的演化存储为多个版本。

注意：Ｓｔａｒｂａｓｅ公司的ＳｔａｒＴｅａｍ是相对较新的产品，包括服务器、桌面客户、Ｗｅｂ界面，提供了源代码管理、缺陷跟踪和线程信息功能。

　对于RichEditor，使用了Microsoft的SourceSafe产品。

它相对较为便宜，并容易得到。

SourceSafe的工作方式与Windows文件系统非常相似。

可以将程序中的所有目录和文件都添加到SourceSafe。

然后SourceSafe将对源代码（或其他检入的文件）进行写保护。

当您打算修改文件时，可以检出这些文件。

本质上，检出文件将把文件复制到本地驱动器并使之可写。

注意：对于您所使用的产品，请查询用户指南。

不幸的是，即使是版本控制机制也并未一致采用。

它需要软件过程管理机制的支持，许多开发团队尚未使用源代码控制机制。

因此，关于如何使用源代码控制程序的书籍也相对较少。

实际上，只要人需要在计算机上进行脑力工作，那么任何行业都需要版本控制产品，如律师、法律书记人员和图形艺术家。

　通过使用诸如StarTeam和SourceSafe之类的版本控制产品，可以避免在不注意的情况下修改或删除文件，并阻止可能出现的并发修改，排除代价高昂的改动丢失情况。

18.2 开发中的Delphi工程选项在开发过程中，Delphi的IDE中的工程选项可以进行限制性最强的设置。

这使得Delphi能够尽早的帮助发现和解决问题。

Project Option对话框包括许多属性页，其中有许多有用的选项，有助于工程的一般组织并可以向每个应用程序添加特定于工程的细节。

18.2.1 应用设置Project Option对话框的Application属性页可用于指定应用程序的标题、帮助文件的位置，以及工程的图标。

应用程序的标题是Rich Text Editor，并选定了一个合适的图标。

可以使用Browse按钮来指定帮助文件。

这些选项被编码到工程的.DPR文件中，如下所示。

Application.HelpFile := 'E:\Books\Osborne\Delphi 6 Developer''s Guide\Chapter18\Examples\RichEditor\Help\RichEditor\RICHEDITOR.HLP';请记住，设计时的环境可能无法映像到部署环境。

实际上部署环境是无法预测的，因此诸如帮助文件路径的信息必须通过编程动态确定。

在主窗体的FormCreate事件中添加下面的代码，即可解决该问题。

Application.HelpFile := ExtractFilePath(Application.EXEName) + 'RichEditor.hlp';除了要编写代码来动态解析帮助文件的路径之外，需要把动态信息存储到注册表或.INI文件中。

RichEditor.exe程序使用了注册表。

图18.1 程序开发过程中的Compiler选项设置图示一项很好的标准是解决所有以前编译器提示、警告或错误的代码。

另外，可以注意到（见图18.1）Message选项Show Hints和Show Warnings 均被选中。

在发布程序或VCL组件之前解决所有的编译器提示和警告是个好习惯。

编译器提示和警告越早越容易解决。

提示和警告实际上是潜在的错误，在其演变成错误之前较为容易解决。

18.2.4 加入版本信息Project Option对话框的Version Info属性页可用于向应用程序加入内部版本信息。

选中Include version information in project复选框以及Auto-increment build number选项，每次选择Project Build菜单项时，编译器将自动更新程序的Build号码并存储版本信息。

Version info属性页底部的Key和Value表格可以在程序中对版权、商标、版本信息以及自定义数据等进行编码。

在File Properties对话框的Version属性页上可以看到该信息。

Major、Minor、Release、Build号码是由About对话框上的TVersionLabel控件使用的，用于自动更新程序的版本和建立信息（使用TVersionLabel组件的源代码，请参见第10章）。

18.2.5 在RichEditor工程中指定目录和条件选项协调工程目录、源代码控制目录、文件物理位置最简单的方法是对三者使用相同的路径。

有时候懒一点也是有好处的。

注意：也许您听说过关于某些罕见的程序员的神话，他们编程的速度比平均速度快上十倍。

这种人确实存在。

他们像西部片中的枪手一样傲慢地迈着方步，仿佛有某些秘密一样。

他们成功的秘密在于习惯。

超级程序员所做的大部分事情都是纯粹、几乎不经大脑的习惯。

他们有一种内部的风格指南，你可以认为这是一种地图，大部分时候都可以告诉他们做什么。

如果还有余下18.3 建立主窗体对工作的描述表明了RichEditor必须能够同时编辑多个Rich Text或文本文件。

对于多个文档的编辑，较为理想的是多文档界面（MDI）协议，我们将在稍后讨论MDI。

该程序是Windows程序，而且是编辑器。

因此，它需要一个主菜单。

大部分用户都需要工具栏和状态栏，因此还要向程序添加工具栏和状态栏。

TTimer组件的OnTimer事件用于按固定的时间间隔更新状态栏，而且将使用新的TAction组件来提供基本的文件输入/输出、编辑菜单、字体格式化等功能。

注意：当程序随时间演化时，请记住开发者的首要目标是尽可能少写代码。

由于我是个喜欢编写代码的人，因此我必须在编写代码的乐趣与经常存在的业务方面的需求进行协调，以避免编写太多的代码。

“请记住，成功的开发者只需编写少量的高质量代码，而不是大量普通的代码（Ｂｏｏｃｈ，１９９６）。

”　到现在为止，我们还没有讨论过MDI程序，本节我们将从创建窗体开始，自顶向下进行工作，最后分别以状态栏和TApplication组件结束。

18.3.1 多文档界面MDI是指可以在一个父窗口中打开多个子窗口。

它与单文档界面（SDI）程序相对，后者是基本的Windows风格的程序。

MDI多用于字处理和电子表格程序，其中用户需要同时在多个文档上工作，对于程序员来说，子窗体是与用户每次工作的文档或工作表相对应的。