使用VBA在办公室2007年应用程序?
-
02-07-2019 - |
题
是VBA要走开很快的任何时间,如维生素b6?我不应该开发新的办公应用程序与VBA?或我应该开发所有新的办公应用程序与应用程序级?
更新:最近读这个 文章.
解决方案
Office VSTO提供了大量超过Office VBA的附加功能,虽然我不相信微软已经表示它将终止VBA(事实上,他们已明确表示将至少在Office 14之前; Office 2007 = Office 12),我认为将您的应用程序迁移到VSTO以利用额外的灵活性和功能是非常值得的。
我实际上并不认为弃用VBA是可行的,因为相当数量的Office编程是由业务用户在宏观层面进行的,我认为这不会很快消失。那些人通常无法访问支持VSTO的IDE。
其他提示
应用程序级具有新特点,但也有一些重大缺陷与VBA。
对于一件事情,代码的访问的安全可以使它难以部署应用程序级应用程序(这是礼貌).
另一个外接程序发展的环境是远为可以"用户"开发商作为VBA。例如,没有宏记录以让你开始。
和一个很大的依次是这样。净互操作的过程COM对象不良好工作。例如,如果您想操纵其他办公室应用程序(文字、PowerPoint、Outlook)从内Excel应用程序级的应用程序,你会发现多副本,这些应用程序运行的背景下,对原因的描述 这KB的文章.
所有这一切再加上巨大的投资,在现有VBA应用程序意味着VBA不会去任何时候很快。
微软已声明 VBA将得到支持在可预见的未来前进,但他们也建议新的应用程序使用VSTO。
最新的Mac版MS Office不支持VBA,64位Windows以虚拟32位进程外模式运行它。因此,如果您计划使用Office作为平台的新应用程序,VSTO 绝对的方式,但您不应过分担心遗留支持。
正如@cori所指出的那样,对于MS而言,仅仅支持并打破如此多的现有软件将是一个很大的营销禁忌。
自从.NET发布以来,微软一直在使用集成的VSTO(可能与V6集成VB6 IDE的方式相同,因为VS IDE将集成到VSTO)的管理代码版本中提示。首次发布。
考虑到涉及多少编码 - 并且考虑到这不会产生用户可见的任何功能 - 我非常怀疑这在Microsoft优先级列表中是高的。我可以想象他们在现有代码库的顶部层叠了一个托管代码集对象(就像Joel Spolsky在首先将VBA放入Excel时将现有C代码库上的一组COM对象分层)并打开一个新的IDE在默认情况下,隐藏旧的。即便如此,这也是一项重要的练习(想象一下编写宏录音机!)。当然,这会使.NET成为Office的预先请求,Office团队只会在枪口下接受。
他们永远不会真正从产品中删除VBA,当然 - Excel仍然支持Excel 4宏,而Word仍然有WordBasic Automation对象来支持Word 6宏,并且没有任何迹象表明要删除它们,因为那里遗留的代码太多了 - 而且没有人在十年内使用过任何一种编码模型。
如果微软确实将.NET环境放入Office(坦白地说,我怀疑它会发生),那么他们可能会停止为新的Office功能添加VBA支持。这是他们最接近停止VBA的。
以下是来自的评论Microsoft 关于未来的VBA支持。简而言之,它不会在Windows版本的Office上消失(但对于Mac版本已停止使用)。
VBA离折旧还有很长的路要走,事实上VBA将被重新引入到MAC的下一个版本的Office中( http://www.microsoft.com/presspass/press/2008/may08/05-13MacBU2008PR.mspx )。
对于大多数人来说,VBA和C XLL(以及VB6 !!)仍然是首选工具。当前的.NET链接速度很慢,并且可以实现零生产率增益。像ExcelDNA这样的第三部分工具可以缓解一些痛苦,但很明显Office的非托管C(和基于汇编程序)的代码库并不容易与.NET搭配。
VBA加载项部署有点麻烦,但VSTO更是如此。此外,VSTO需要一些开销,因为它需要在运行代码之前启动CLR。
但最重要的是; VSTO消除了写VBA的痛苦。