VB程序设计一般的四个步骤

1、建立应用程序界面

2、设置对象的属性

3、编写应用程序的代码

4、保存和运行程序

VB拥有图形用户界面（GUI）和快速应用程序开发（RAD）系统，可以轻易的使用DAO、RDO、ADO连接数据库，或者轻松的创建Active X控件，用于高效生成类型安全和面向对象的应用程序。程序员可以轻松的使用VB提供的组件快速建立一个应用程序。

扩展资料

VB语言缺点

Visual Basic 语言具有不支持继承、无原生支持多线程、异常处理不完善等三项明显缺点，使其有所局限性（此些缺点皆已在 vb .net 获得改进）。

1、不支持继承

VB 5.0 和 VB 6.0 都是基于对象的编程语言，但是不包含继承特性。VB 中提供了特殊的类的功能，但是还是不能满足程序员的需求。

2、无原生支持多线程

Visual Basic 对于多线程无原生支持，只能通过Windows API的调用实现，且极其的不稳定。因为在API创建的线程中，并没有自动初始化运行时库，导致部分的函数无法使用。一般的，在VB6等早期的VB开发环境下，使用API创建线程的目的是完成容易使程序假死的大量数据或者逻辑的计算。

3、异常处理不完善

Visual Basic 中内置异常处理，即使未写异常处理代码，一旦用户出错也会d出一个明确写出出错原因对话框，接着程序终止。

Visual Basic 中可以使用 Err.Raise抛出异常。对系统及用户抛出的异常的处理常用两种模式：一是使用 On Error Resume Next 处理错误；另一种是使用 On Error Goto 将运行引入错误处理代码。但相对 C++ 等语言而言，这样的异常处理破坏了代码的结构。

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

什么是好的界面

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

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

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

Windows 界面准则

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

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

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

可用性的检测

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

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

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

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

功能的可发现性

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

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

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

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

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

创建容易理解的对话框

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