VisualBasic程序设计

　　可用性设计
　　任何应用程序的可用性基本上由用户决定。界面设计是需多次反复的过程；在为应用程序设计界面时，第一步就设计出非常完美的界面的情况非常少见。用户参与设计过程越早，花的气力越少，创建的界面越好、越可用。
　　
　　什么是好的界面
　　设计用户界面时，开始时最好是先看看Microsoft或其他公司的一些卖得很好的应用程序。毕竟，界面很差的应用程序不会卖得很好。将会发现许多通用的东西，比如：工具栏、状态条、工具提示、上下文菜单以及标记对话框。VisualBasic具有把所有这些东西添加到应用程序中的能力，这并不偶然。
　　也可以凭借自己使用软件的经验。想一想曾经使用过的一些应用程序，哪些可以工作、哪些不可以以及如何修改它。但要记住个人的喜好不等于用户的喜好，必须把自己的意见与用户的意见一致起来。
　　还要注意到大多数成功的应用程序都提供选择来适应不同的用户的偏爱。例如，MicrosoftWindows“资源管理器”允许用户通过菜单、键盘命令或者拖放来复制文件。提供选项会扩大应用程序的吸引力，至少应该使所有的功能都能被鼠标和键盘所访问。
　　
　　Windows界面准则
　　Windows操作系统的主要的优点就是为所有的应用程序提供了公用的界面。知道如何使用基于Windows的应用程序的用户，很容易学会使用其他应用程序。而与已创建的界面准则相差太远的应用程序不易让人明了。
　　菜单就是这方面很好的例子——大多数基于Windows的应用程序都遵循这样的标准：“文件”菜单在最左边，然后是“编辑”、“工具”等可选的菜单，最右边是“帮助”菜单。如果说Documents会比File更好，或者“帮助”菜单要放在最前，这就值得讨论一下了。没有任何事情阻止您这样做，但这样做会引起用户的混淆，降低应用程序的可用性。每当在应用程序与其他程序之间切换时，用户都不得不停下来想一想。
　　子菜单的位置也很重要。用户本期望在“编辑”菜单下找到“复制”、“剪切”与“粘贴”等子菜单，若将它们移到“文件”菜单下会引起用户的混乱。不要偏离已经创建的准则太远，除非有很好的理由这样做。
　　
　　可用性的检测
　　测试界面可用性的最好方法是在整个设计过程中请用户参与。不论是正在设计大型的压缩包应用程序，还是小型的有限使用的应用程序，设计的过程应当完全相同。使用已创建的设计准则，界面设计应从纸上开始。
　　下一步是创建一个或者多个原型，在VisualBasic中设计窗体。还需要增加足够的代码来启动原型：显示窗体、用示例数据填充列表框等等。然后准备可用性测试。
　　可用性测试可以是个不拘形式的过程：与用户一道审查设计；也可以是在已创建的可用性实验室中进行的正式的过程。这两种方法目的是一样的：从用户那儿了解哪儿设计得很好，哪儿还需要改进的第一手材料。放开，让用户与应用程序在一起，然后观察它们；这种方式比询问用户更为有效。当用户试图完成一系列任务时让他们表达其思考过程：“要想打开新文档，所以要在‘文件’菜单中找一找。”记下哪些地方的界面设计没有反应他们的思考过程。与不同类型的用户一起测试，如果发现用户完成某个特定的任务有困难，该任务可能需要多加关照。
　　下一步，复查一下记录，考虑如何修改该界面使它更加可用。修改界面并再测试。一旦对应用程序可用性满意，就准备开始编码。在开发的过程中也需要不时地测试来确保对原型的设想是正确的。
　　
　　功能的可发现性
　　可用性测试的关键的概念是可发现性。如果用户不能发现如何使用某个功能（或者甚至不知道有此功能存在），则此功能很少有人去使用。例如，Windows3.1的大多数用户都从来不知道ALT和TAB的组合键可以用于在打开的应用程序之间切换。界面中没有任何地方可提供线索来帮助用户发现这一功能。
　　为了测试功能的可发现性，不解释如何做就要求用户完成一个任务（例如，使用“窗体模板”创建新文档）。如果他们不能完成这个任务，或者尝试了好多次，则此功能的可发现性还需要改进。
　　
　　当用户或系统出错时与用户交互
　　在理想世界里，软件与硬件都会无故障地一直工作下去，用户也从不出错。而现实中错误总是难免的。决定当事情出毛病时应用程序如何响应，是用户界面设计的一部分。
　　常用的响应是显示一个对话框，要求用户输入应用程序该如何处理这个问题。不太常用（但更好）的响应是简单地解决问题而不打扰用户。毕竟，用户主要关心的是完成任务，而不是技术细节。在设计用户界面时，考虑可能出现的错误，并判断哪一个需要用户交互作用，哪一个可以按事先安排的方案解决。
　　
　　创建容易理解的对话框
　　偶尔应用程序中会出现错误，需要为解决这种情况做出判断。这通常作为代码的分支出现——If...Then语句或者Case语句。如果这个判断需要与用户交互，此问题通常用对话框来提交用户。对话框是用户界面的一部分，像界面的其他部分一样，它们的设计在应用程序可用性中发挥了作用。
　　有时有这样的感觉，好像许多程序对话框的设计员，不会讲使人容易理解的话。比如这样的消息：“硬盘C的扇区被损坏或不能访问。中止、重试、忽略？”（见图6.22）这对一般的用户而言不大好理解。这等于有侍者问顾客：“我们没有汤或者厨房正在生火，中止、重试、忽略？”您会如何回答呢？以用户能理解的方式或短语描述问题（和选择）是重要的。在前面的例子中，更好的消息可以是“在C盘上存文件有问题，请把文件存于A盘。存不存文件？”
　　
　　当为应用程序创建对话框时，心里想着用户。这个消息给用户传达了有用的信息吗？它容易理解吗？命令按钮表示的选择明确吗？这选择适合给定的条件吗？记住，仅仅一个讨厌的消息框就会使用户对应用程序产生坏印象。
　　如果正在设计自定义对话框，尽量坚持用标准类型。如果与标准消息框布局相差太远，用户可能不会把它认作是对话框。
　　详细信息关于对话框的详细内容，请参阅本章前面的“对话框”。
　　
　　不用对话框的错误处理
　　当错误出现时不一定要打断用户。有时更可取的是不通知用户而用代码来处理错误，或者以不停止用户工作流程的方法来提醒用户。这个技术的很好的例子是MicrosoftWord中的“自动更正”功能：如果普通单词拼错了，Word自动修改它；如果不常用单词拼错了，在其下划一条红线提醒用户以后改正。
　　有大量的技术可以使用；哪些技术适用于应用程序应由自己决定。这里有几个建议：
　　1.在“编辑”菜单中添加“撤销”功能。对于删除等情况，与其用“确定”对话框来打断用户，还不如确保他们作出正确的决定并提供“撤销”功能以备他们以后改变主意。
　　2.在状态栏或图标上显示消息。如果错误不影响用户当前的任务，不要停止应用程序。使用状态栏或亮色警告图标来警告用户，当他们准备好后可以处理该问题。
　　3.改正问题。有时错误的解决办法很显然。例如，当用户试图存文件时磁盘已满，则在其他驱动器中检查系统寻找空间。如果空间可用，则保存该文件；在状态栏中显示一条消息告诉用户做了些什么。
　　4.保存消息等候处理。因为不是所有的错误都是紧要的，或要求马上注意的；考虑把这些记录到文件中，当用户退出应用程序时或其他方便的时候再把它们显示给用户。如果用户发生输入错误（如：把MainSt.写成MianSt.），记录它。添加“ReviewEntries”按钮和显示差异的函数，以便用户可以改正它们。
　　5.不要做任何事。有时错误并不重要，不足以成为警告的原因。例如，LPT1上的打印机的纸张没准备好这一事实，在准备打印之前并没有多大关系。等待，直到消息合乎当前的任务。
　　详细信息关于错误处理技术的详细内容，请参阅第十三章“调试代码与处理错误”。
　　
　　设计用户辅助模式
　　不论用户界面设计得多么好，有时用户总需要帮助。应用程序的用户辅助模式包括诸如联机帮助和打印出来的文档等东西；它也可以包括用户辅助设备，如工具提示、状态条、“这是什么”帮助以及向导。
　　像应用程序的其他任何部分一样，用户辅助模式设计应当在开始开发之前。模式的内容将随着应用程序的复杂程度与预期读者的不同而不同。
　　
　　帮助与文档
　　联机帮助是任何应用程序的重要部分，它通常是用户有问题时最先查看的地方。甚至简单的应用程序也应该提供“帮助”。不提供它就好像是假定用户从来不会有问题。
　　在设计“帮助”系统时，记住它的主要目的是回答问题。创建主题名称与索引条目时尽量用用户的术语，例如，“我如何格式化页面？”比“编辑”，“页格式”菜单更容易找到主题。不要忘记上下文相关性；对大多数用户而言，如果他们按下F1键寻求一指定字段的帮助，却发现自己在内容主题上，则他们会感到受挫折。
　　基本概念的文档，不管是打印的和/或由压缩盘提供的，对所有的应用程序都是有帮助的，除了最简单的以外。它可以提供那些用简短的“帮助”主题难以传达的信息。至少，应该在ReadMe文件窗体中提供用户在需要时可以打印的文档。
　　
　　用户辅助设备
　　在用户界面中，有几种对用户提供辅助的技术。用VisualBasic在应用程序中添加工具提示、“这是什么”帮助、状态显示和向导是很容易的。这些设备中的哪些适用于自己的应用程序应由自己决定。
　　
　　工具提示
　　当用户在用户界面上搜索时，工具提示（图6.23）是一种向他们显示信息的好方法。工具提示是个小标签，当鼠标指针在控件上停留会儿即显示，通常包含此控件的功能描述。正常情况下工具提示与工具栏结合使用，它在界面的大多数部分也能很好工作。
　　
　　大多数VisualBasic控件都包含用来显示工具提示的属性：ToolTipText。以下代码将对名为“cmdPrint”的命令按钮提供工具提示。
　　cmdPrint.ToolTipText="Printsthecurrentdocument"
　　像界面的其它部分一样，要确保此文本能明确地传达给用户的消息。
　　详细信息关于工具提示的详细内容，请参阅《语言参考》的“ToolTipText属性”。
　　
　　“这是什么”帮助
　　当用户选取“这是什么”帮助并单击控件上的“这是什么”光标，“这是什么”帮助提供了和弹出式“帮助”主题（见图6.24）的链接。“这是什么”帮助可以从工具栏按钮、菜单项或者对话框的标题栏上的按钮启动。
　　
　　要从菜单或工具栏使“这是什么”帮助有效，请按照以下步骤执行：
　　1.选取希望为其提供帮助的控件。
　　2.在“属性”窗口中，选取WhatsThisHelpID属性。
　　3.为相关的弹出式“帮助”主题输入上下文标识符号。
　　4.为任何其他控件重复步骤1到步骤3。
　　5.选取窗体。
　　6.在“属性”窗口中，设置该窗体的WhatsThisHelp属性为True。
　　7.在菜单或工具栏按钮的Click事件中，键入以下代码：
　　formname.WhatsThisHelp
　　当用户单击该按钮或菜单时，鼠标指针会改变为“这是什么”帮助指针。为了使在自定义对话窗体的标题栏上的“这是什么”帮助有效，设置该窗体的WhatsThisButton与WhatsThisHelp属性为True。
　　详细信息关于“这是什么”帮助的详细内容，请参阅《语言参考》的“WhatsThisHelp属性”与“WhatsThisButton属性”。
　　
　　状态显示
　　状态显示也可用与工具提示差不多的方法来提供用户辅助设备。状态显示是提供那些不太适合工具提示的指令或消息的一种好方法。包括在VisualBasic的专业版与企业版中的状态条控件能很好地显示消息；Label控件也能用作状态显示。
　　在状态显示中显示的文本可以用以下两种方法中的一种来更新：用控件或窗体的GotFocus事件，或者用MouseMove事件。如果想把显示用作学习设备，在Help菜单中添加一个项目来转换其Visible属性的开与关。
　　要添加状态显示，请按照以下步骤执行：
　　1.在窗体中添加Label控件。
　　2.选取希望为其显示消息的那个控件。
　　3.在控件的MouseMove（或GotFocus）事件中添加以下代码：Labelname.Caption="Enterthecustomer'sIDnumberinthisfield"当鼠标移到该控件上时，这条消息将显示在此Label控件中。
　　4.为任何其它的控件重复步骤2到步骤3。
　　
　　向导
　　向导是一种用户辅助设备，它引导用自己的实际数据一步一步地实现一个过程。向导通常用来提供任务专用辅助。它们帮助完成需要相当长的（而且令人讨厌的）学习过程的任务，它们给还没有成为专家的用户提供专家信息。
　　VisualBasic的专业版与企业版包括了创建向导的工具：向导管理器。
　　详细信息关于向导的详细内容，请参阅第四章“工程的管理”中的“使用向导与外接程序”。