vb6 0精简版（vb6.0简体中文企业版）

VB/VBA的IDE究竟需要什么？1、前面给大家介绍了两个优秀的IDE插件，可以说无论是UI的豪华层面，还是干饭的干货层面，都极具代表性。尽管如此，它们仍然在应用过程中饱受诟病，也并没能拯救VB/VBA的颓势，为什么呢？2、深层次的原因还是在于基因的问题，当年的BASIC就是用于教育目的，只不过后来在微软手上又持续加入了很多彩蛋。普遍用于教学的编程工具，而且对象是广大非计算机专业人士，那就不得不舍弃一些专业的晦涩，提升一些编程的乐趣。从这一点上，VB就不能，也不应当与其他专业工具比较专业性。VB曾经的确红火过，但那属于计算机软件业拓荒的野蛮时代，任何一个行业最终都会交由那些精通的专业人士来维护，而VB前后的遭遇正好印证了这样的市场法则。VB经过微软的改造，尤其是与VS6.0的战略协同，拥有了不错的专业性。但是，桌面工具与硬件端捆绑得太死，迟早会被网络化的轻模式威胁。JAVA的异军突起，让微软在战略上倍感压力，不得不上马.NET加以应对。微软当然清楚，这场战斗中，群演的VB疗效甚微。所以“能用，够用”就成了这一产品的未来最好的结局。自然，进入NT时代以后，VB家族就没有重大更新，始终维持在『可用』级别上，无论是VB6、VBA，还是VBS，无不是如此。2008年4月，微软更是官宣停止VB6的IDE更新。64位的OfficeVBA和VBS，虽然升级到了64位，但IDE功能上，还是老样子。这和后来的社会化大分工，是紧密相关的。软件业，不再像当年那样稀缺开发人员，相反程序员成为了一个庞大的职业群体。VB当年定位的普罗百姓，也不再需要通过编程才能使用计算机。所以，在这种分工背景下，注定了VB的用户属性，编程属性也仅仅是弥补通用软件的定制不足。所以，可用和够用，对于这一群体而言，是一个恰当的定位，而VB的IDE进化缺乏市场支持后，也只能保持原地不动。3、VB的IDE停更，并不意味着直接宣判这类产品的死刑，而是将其整体打包到Win32生态兼容上。虽然，20多年后，再看VB的IDE，确显古老，但这并不意味着IDE无法被改造。VB从4.0开始全面拥抱COM，到了6.0时已经运用得炉火纯青。VB的IDE也自然不会放过COM，也正是因为如此，VB的IDE提供了大量的二开接口，用户可以很方便使用这些接口来扩展IDE。所以，笔者曾说，官方停更了，难道自己就不能DIY了吗？4、所以，才有前几篇提到的这些IDE插件。但是它们在扩展IDE时，都没有将本身的意义梳理清楚。微软官方提供的IDE（包括滚轮支持），对于该工具的市场定位是足够的。如果要扩展，有两个方面是不能避免的。一是，不能破坏易用性。如果将VB进化成Delphi那样的专业工具，VB就不是VB了。易用性，不仅包括用户易于使用，更在于在理解上没有很高的门槛。ThunderVB，虽然容易使用，但是它提高了理解的门槛，将VB变成了一个低端版的Delphi。所以，最终也消失在了人们的视野中。二是，能够拓展VB的边界。VB的IDE够用，并非一句空话。语法智能提示不说，就代码自动补全上，虽不能和现代的VSCode的函数补全相提并论，但毕竟也是有的。其他不能自动补全的，手工输入，其实也并不是个事，反倒是编码素养的问题。代码块的定位，可能最受诟病，但是鼠标滚轮+函数列表+资源模块列表+全模块和单函数显示模式，什么样的代码不能定位呢？非要折叠代码块吗？VB/VBA的IDE环境可是要支持解释运行源码的，折叠了还怎么运行？凡是那些能折叠代码块的，哪一个能支持逐行源码解释的？缩进格式，这个更是编码人员自身素养的问题。VB的IDE提供了代码块缩进支持，就是Tab/ShiftTab，缩进与恢复缩进代码块，格式什么的真不是问题。CodeSMART为了这些与编码人员素质相关的问题，不仅花费了大量的界面，也牺牲了IDE的性能和健壮性。所以，很多用户反馈，用了之后无法正常退出工程，莫名的卡顿，界面过于繁杂等等。究其原因，就是没能抓住拓展边界的属性。5、拓展VB的边界和不破坏易用性，往往自成一对矛盾。VB作为VS的一员，在开发过程中使用了大量系统性的资源，但最终呈现给用户的却极少，这便是VB中的彩蛋。IDE的开发人员，其实不必自寻思路，仅需将这些彩蛋找出来，以一个合理的方式呈现给用户，就能极大地拓展VB的边界。而这个合理的方式，就是要像VB/VBA所呈现的那样，在概念上必须再次抽象，不能让用户直面那些专业的概念。要做到这一点，绝非易事。[心]欢迎关注BtOfficer[心]（收藏、点赞、关注+转发）,更多精彩仍在继续哦（专栏文章将更系统，更全面，但需要阁下支持哦），有严肃的技术，也有轻松的唠嗑，期待你的加入！