还有人用Visual Basic开发程序吗？大部分搞开发的还是对它有情怀

有没有人和我一样，当年自学 VB 的，当年怕爱不释手的折腾了半年时间，现在回想起来当时还是挺好学的。

vb全称是Visual Basic，是微软开发的一种通用的基于对象的程序设计语言，同时还是一种可视化的程序设计语言，是可用于微软自家产品开发的语言。

Visual 指的是开发图形用户界面 (GUI) 的方法，不需编写大量代码去描述界面元素的外观和位置，而只要把预先建立的对象add到屏幕上的一点即可。

Basic指的是 BASIC (Beginners All-Purpose Symbolic Instruction Code) 语言，是一种在计算技术发展 历史 上应用得最为广泛的语言。

Visual Basic 源自于BASIC编程语言。VB拥有图形用户界面（GUI）和快速应用程序开发（RAD）系统，可以轻易的使用DAO、RDO、ADO连接数据库。

能用VB做的事情有很多，基本上除了底层开发(系统软件)，VB都能做，而且在数据库应用方面VB也有他独到的一面；vb拥有强大的数据库功能，可以访问Access、FoxPro等多种数据库系统，而且还能够访问多种电子表格。

或者轻松的创建Active X控件，用于高效生成类型安全和面向对象的应用程序 ，程序员可以轻松的使用VB提供的组件快速建立一个应用程序。

VB只能用于设计一些比较小的程序，目前有少部分人在用，学校很多，工作上也会用到，但是广泛程度当然没有JAVA和C#还有.NET这些相比。

今天给大家分享下当年自学VB后就激动的上手开发一些小功能程序，以下分享的是界面，一起怀旧下：

这个是启动软件的界面，自己凭想象弄了一个变色的。

当年QQ农场还比较火热的，就学习开发了这个刷经验的。

当年去电玩室，玩老虎机，想着开发一个相似的程序。

当时也在学数据库，就写了一个查询、读取数据的。

这也是前台 *** 作，后台写入数据库的发货单程序 。

当年也经常配电脑，就写了这个[捂脸]

当时工作单位是餐饮，就开发了这个排对取号单和发票管理小程序。

这个是为点菜做了个商品检索。

后边数据库学了一段时间，就开发了这个小型工资管理系统。

这几个也是数据库（增、删、改、查）的。

发现当时很闲啊[捂脸]，做了个程序运行时间计时器和程序最小化到托盘打开调用窗体的小程序 。

学习调用API后，做了这个锁屏工具。

又做了个浏览器，后边这个是前台界面，查询员工的。

这是在另一家餐饮公司，学着开发的一些常用功能，这个主页界面。

今天突然从相册里翻到这些，都是满满的回忆，分享给和我一样，喜爱VB的人，谢谢大家！！！

可用性设计

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

什么是好的界面

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

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

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

Windows 界面准则

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

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

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

可用性的检测

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

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

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

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

功能的可发现性

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

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

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

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

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

创建容易理解的对话框

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

---