Excel加载项和VBA引用的范围是什么? [英] What is the scope of Excel add-in's and VBA references?

查看:128
本文介绍了Excel加载项和VBA引用的范围是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当我安装外接程序(通过复选框)时,控制该外接程序保持安装时间的规则/机制是什么?它似乎已安装在应用程序级别,这意味着它适用于excel应用程序中的任何工作簿,直到您自己取消选中它为止。如果这是正确的,则意味着只要用户自己安装外接程序,它们就可以了。但是他们必须在第一次安装它(可以通过编程方式完成。)。



关于VBA引用,我想不需要每次都对它们进行检查 -表示它在文档范围内。但是,如果这是真的,为什么人们建议在准备发布软件时使用后期绑定方法?后期绑定是否真的只是为了使它与不同版本兼容,而不一定是为了使它被选中作为参考?在这种假设下,只要每个人都使用与我相同的Excel版本,就可以安全地放弃将所有后期绑定在一起,而只是手动添加引用吗?

解决方案

插件已安装到应用程序级别。您可以根据需要使用功能区XML来微调外接程序如何向(或不向)各种工作簿公开。


只要用户自己安装添加项,就可以了;但是他们将不得不在第一次安装它。


是的,他们将不得不安装它。


关于VBA引用,我想不需要每次都对它们进行检查,这意味着它在文档范围内。


是的,版本控制。这也免除了您尝试以编程方式添加引用的麻烦。这可以通过路径(需要了解操作系统,版本等)或GUID(我从未真正能够成功完成)来完成。然后,这两个方法都需要进行错误捕获(如果路径不存在或无法访问该怎么办?等)。因此,只使用后期绑定即可。



虽然使用早期绑定开发很有帮助,因为从用户的角度来看,智能感知从总体上看并没有明显的区别,尽管EB可以说是更快,但对于大多数应用而言,差异通常可以忽略不计。相关的,如果在使用EB时您依赖 New 关键字实例化对象,我相信您可以使用 CreateObject 函数与LB配合使用实际上更快。


我可以放弃后期绑定吗,并且只需手动添加引用就可以安全吗? / p>

我只需使用EB进行开发,然后在编译外接程序之前将代码修改为后期绑定的对象。


When I install an add-in (via the checkbox) what are the rules / mechanics governing how long that add-in stays installed? It seems that it is installed on the application level, meaning that it applies to any workbook in the excel application, until you uncheck it yourself. If this is correct, this means that as long as a user installs the add-in themselves, they should be fine; but they will have to install it that first time (which could be done programmatically).

Regarding VBA references, I imagine these do not need to be 'checked' every time- meaning it is in the scope of the document. But if this is true, why do people recommend using late binding methods when the software is ready to be distributed? Is late binding really just to make it compatible with different versions, but not necessarily to make it so the DLL is 'checked' as a reference? Under this assumption, as long as everyone uses the same version of Excel as the me, would it be safe to forego late binding all together, and just add the references manually?

解决方案

Add-ins are installed to the Application-level. You can fine-tune how an Add-in may be exposed (or not) to various Workbook(s) using Ribbon XML if needed.

as long as a user installs the add in themselves, they should be fine; but they will have to install it that first time

Yes, they'll have to install it.

Regarding VBA references, I imagine these do not need to be 'checked' every time- meaning it is in the scope of the document.

Yes, version control. It also saves you the hassle of having to try and programmatically add references. This can be done by path (which requires knowing the OS, version, etc. ) or the GUID (I've never actually been able to do this successfully). Both of these would then require error-trapping (what if the path doesn't exist or is otherwise inaccessible? etc.). So just use late binding.

While developing using early binding is helpful because of the intellisense, from a user perspective, there is generally no observable difference in how they might perform although EB is arguably faster, the difference is usually negligible for most applications. Related, if while using EB you rely on the New keyword to instantiate objects, I believe that the CreateObject function which you would use with LB is actually faster. This is probably not noticeable, though.

can I forego the late binding all together, and be safe by just adding the references manually?

I would simply do the development with EB, and then modify the code to late-bound objects before compiling the Add-in.

这篇关于Excel加载项和VBA引用的范围是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆