VisualBasic程序设计

可用性设计

任何应用程序的可用性基本上由用户决定。界面设计是需多次反复的过程；在为应用程序设计界面时，第一步就设计出非常完美的界面的情况非常少见。用户参与设计过程越早，花的气力越少，创建的界面越好、越可用。

什么是好的界面

设计用户界面时，开始时是先看看 Microsoft 或其他公司的一些卖得很好的应用程序。毕竟，界面很差的应用程序不会卖得很好。将会发现许多通用的东西，比如：工具栏、状态条、工具提示、上下文菜单以及标记对话框。Visual Basic 具有把所有这些东西添加到应用程序中的能力，这并不偶然。

也可以凭借自己使用软件的经验。想一想曾经使用过的一些应用程序，哪些可以工作、哪些不可以以及如何修改它。但要记住个人的喜好不等于用户的喜好，必须把自己的意见与用户的意见一致起来。

还要注意到大多数成功的应用程序都提供选择来适应不同的用户的偏爱。例如，Microsoft Windows“资源管理器”允许用户通过菜单、键盘命令或者拖放来复制文件。提供选项会扩大应用程序的吸引力，至少应该使所有的功能都能被鼠标和键盘所访问。

Windows 界面准则

Windows *** 作系统的主要的优点就是为所有的应用程序提供了公用的界面。知道如何使用基于 Windows 的应用程序的用户，很容易学会使用其他应用程序。而与已创建的界面准则相差太远的应用程序不易让人明了。

菜单就是这方面很好的例子——大多数基于 Windows 的应用程序都遵循这样的标准：“文件”菜单在最左边，然后是“我”、“工具”等可选的菜单，最右边是“帮助”菜单。如果说 Documents 会比 File 更好，或者“帮助”菜单要放在最前，这就值得讨论一下了。没有任何事情阻止您这样做，但这样做会引起用户的混淆，降低应用程序的可用性。每当在应用程序与其他程序之间切换时，用户都不得不停下来想一想。

子菜单的位置也很重要。用户本期望在“我”菜单下找到“复制”、“剪切”与“粘贴”等子菜单，若将它们移到“文件”菜单下会引起用户的混乱。不要偏离已经创建的准则太远，除非有很好的理由这样做。

可用性的检测

测试界面可用性的方法是在整个设计过程中请用户参与。不论是正在设计大型的压缩包应用程序，还是小型的有限使用的应用程序，设计的过程应当完全相同。使用已创建的设计准则，界面设计应从纸上开始。

下一步是创建一个或者多个原型，在 Visual Basic 中设计窗体。还需要增加足够的代码来启动原型：显示窗体、用示例数据填充列表框等等。然后准备可用性测试。

可用性测试可以是个不拘形式的过程：与用户一道审查设计；也可以是在已创建的可用性实验室中进行的正式的过程。这两种方法目的是一样的：从用户那儿了解哪儿设计得很好，哪儿还需要改进的第一手材料。放开，让用户与应用程序在一起，然后观察它们；这种方式比询问用户更为有效。当用户试图完成一系列任务时让他们表达其思考过程：“要想打开新文档，所以要在‘文件’菜单中找一找。”记下哪些地方的界面设计没有反应他们的思考过程。与不同类型的用户一起测试，如果发现用户完成某个特定的任务有困难，该任务可能需要多加关照。

下一步，复查一下记录，考虑如何修改该界面使它更加可用。修改界面并再测试。一旦对应用程序可用性满意，就准备开始编码。在开发的过程中也需要不时地测试来确保对原型的设想是正确的。

功能的可发现性

可用性测试的关键的概念是可发现性。如果用户不能发现如何使用某个功能（或者甚至不知道有此功能存在），则此功能很少有人去使用。例如，Windows 3.1 的大多数用户都从来不知道 ALT 和 TAB 的组合键可以用于在打开的应用程序之间切换。界面中没有任何地方可提供线索来帮助用户发现这一功能。

为了测试功能的可发现性，不解释如何做就要求用户完成一个任务（例如，使用“窗体模板”创建新文档）。如果他们不能完成这个任务，或者尝试了好多次，则此功能的可发现性还需要改进。

当用户或系统出错时与用户交互

在理想世界里，软件与硬件都会无故障地一直工作下去，用户也从不出错。而现实中错误总是难免的。决定当事情出毛病时应用程序如何响应，是用户界面设计的一部分。

常用的响应是显示一个对话框，要求用户输入应用程序该如何处理这个问题。不太常用（但更好）的响应是简单地解决问题而不打扰用户。毕竟，用户主要关心的是完成任务，而不是技术细节。在设计用户界面时，考虑可能出现的错误，并判断哪一个需要用户交互作用，哪一个可以按事先安排的方案解决 。

创建容易理解的对话框

偶尔应用程序中会出现错误，需要为解决这种情况做出判断。这通常作为代码的分支出现——If...Then 语句或者 Case 语句。如果这个判断需要与用户交互，此问题通常用对话框来提交用户。对话框是用户界面的一部分，像界面的其他部分一样，它们的设计在应用程序可用性中发挥了作用。

Visual Basic 应用程序的结构

一个应用程序实际上无非是指挥计算机完成任务的指令集。应用程序的结构是组织指令的方法，也就是指令存放的位置和指令的执行顺序。

典型的 "hello world" 例子以及诸如此类的简单应用程序都具有简单结构。对于只有一行的代码来说，组织结构并不十分重要。但应用程序越复杂，对组织或结构的要求也就越明显。试想一下，如果允许应用程序以随机顺序去执行，那将会带来什么样的混乱。除了对应用程序的执行进行控制外，如何在应用程序中轻松查找特定指令，结构也起着很重要的作用。

由于 Visual Basic 应用程序是基于对象的，所以应用程序的代码结构就是该程序在屏幕上物理表示的模型。根据定义，对象包含数据和代码。在屏幕上看到的窗体代表属性，这些属性定义了窗体的外观和内在特性。应用程序中的每个窗体都有一个包含其代码的相关的窗体模块（文件扩展名为 .frm）。

每个窗体模块都包含事件过程，即代码部分，其中有为响应特定事件而执行的指令。窗体可包含控件。在窗体模块中，对窗体上的每个控件都有一个对应的事件过程集。除了事件过程，窗体模块还可包含通用过程，它对来自任何事件过程的调用都作出响应。

可将那些与特定窗体或控件无关的代码放入另一类型的模块——标准模块（文件扩展名为 .BAS ）中。一个过程可能用来响应几个不同对象中的事件，应该将这个过程放在标准模块中，而不应在每一个对象的事件过程中重复相同的代码。

用类模块（文件扩展名为 .CLS ）创建对象，这些对象可被应用程序内的过程调用。标准模块只包含代码，而类模块既包含代码又包含数据，可视为没有物理表示的控件。

在第四章“工程的管理”中叙述了哪些部件可以添加到应用程序中，本章将说明如何将代码写到构成应用程序的各种部件中。按照缺省规定，工程包含的窗体模块。可根据需要另行添加窗体、类和标准模块。第九章“用对象编程”将讨论类模块。

事件驱动应用程序的工作方式

事件是窗体或控件识别的动作。在响应事件时，事件驱动应用程序执行 Basic代码。Visual Basic 的每一个窗体和控件都有一个预定义的事件集。如果其中有一个事件发生，而且，在关联的事件过程中存在代码，则 Visual Basic 调用该代码。

尽管 Visual Basic 中的对象自动识别预定义的事件集，但要判定它们是否响应具体事件以及如何响应具体事件则是编程的责任了。代码部分（即事件过程）与每个事件对应。 想让控件响应事件时，就把代码写入这个事件的事件过程之中。

对象所识别的事件类型多种多样，但多数类型为大多数控件所共有。例如，大多数对象都能识别 Click 事件——如果单击窗体，则执行窗体的单击事件过程中的代码；如果单击命令按钮，则执行命令按钮的Click 事件过程中的代码。每个情况中的实际代码几乎完全不一样。

这里是事件驱动应用程序中的典型事件序列：

1. 启动应用程序，装载和显示窗体。

2. 窗体（或窗体上的控件）接收事件。事件可由用户引发（例如键盘 *** 作），可由系统引发（例如定时器事件），也可由代码间接引发（例如，当代码装载窗体时的 Load 事件）。

3. 如果在相应的事件过程中存在代码，就执行代码。

4. 应用程序等待下一次事件。

注意 许多事件伴随其它事件发生。例如，在 DblClick 事件发生时，MouseDown、MouseUp 和 Click 事件也会发生。

---