VBA外部模块

Question

是否有可能让模块在实际Excel文件的外部并在外部调用它们的函数/子系统？

我的想法是，如果有使用相同的模块多个Excel文件，而不是单独更新这些文件中的每一个，当我做出改变，我可以只更新存储在服务器或某事的一个模块？

Answer 1

不知道这是否会满足您的需求，但你可以创建公用模块作为一个“插件”等安装它，以便您在Excel的同一实例中打开所有文件将有机会获得加在代码中。 这不是我推荐的方式，因为我会担心所有使用它的excel文件进​​行适当的测试，当您进行更改时，再加上让用户安装加载项的复杂性（这可能会不是你的问题）。我有一个“developersToolkit”模块，我在8个不同的工作簿中使用，但是我将模块导入到每个工作簿中，以便独立使用，并且我还可以测试与8个工作簿中的每一个兼容的更改。

Answer 2

我已经做了类似你描述多年的事情。您可以将VBA代码移动到VB6 ActiveX dll，将其组织成类，然后将该dll作为Excel VBA的参考加载。

这是重用非工作簿特定代码的好方法。例如，我有查询大型机的代码。我喜欢从Excel中调用它，但是连接的细节以及数据传递的方式都包含在一个dll中，我可以从Excel，VB6，Word，.NET中加载任何地方。我有一个类似的DLL从AutoCAD绘图，一个与一个MySQL服务器上的产品DB接口等

留在Excel中的代码往往是简单格式化的东西读取数据。假设我从我写的某个库中返回了一个字符串变体（技术上是一个COM SAFEARRAY）。然后，我将它输出到Excel中，也许做一个文本到列，并有一个返回给用户的结果列表。

您也可以传递并返回更复杂的数据结构。 VB6/COM自动化的美妙之处（直到我学会了在VB.NET或C＃中使用更难的方式之前，我才感激不尽），数据将无缝地流入和流出组件，并且所有必要的接口将会为你创造。

主要的变化对你的代码将用相同的显式参数（BYVAL SHT为Excel.Worksheet）来替换之类的东西的ThisWorkbook或ActiveSheet。这些将在编译时在VB6中捕获（因为它不知道ThisWorkbook是什么），所以你不能忽视它们;你被迫传递一个明确的参考。

我也注意到，如果它收到一个工作表或其他Excel对象作为参数我的DLL里面的代码变得更加偏执。在VBA中，你可能会有更多的保证，因为它对于给定的工作簿是私有的，所以你传递了一个好的对象。 dll不知道谁在调用它，所以我更怀疑地查看传入的对象（检查是否没有，表名，格式化线索以确保我正在使用我认为正在使用的东西）。

唯一的缺点我看到的是，您将获得Visual Basic 6.0的副本。我在1998年购买了我的产品。微软不再提供这款产品，但肯定有人会将产品出售给您。最新的服务包是SP6。

当您在各种计算机上打开工作簿时，您还必须熟悉“regsvr32”和“regsvr32/u”以处理“ActiveX无法创建组件”错误。我只是将我的dll发布到映射的网络驱动器，并在发生重大变化时将其重新注册到用户的计算机上。显然这是一个内联网/单一公司解决方案。发布更新的版本在分发得越远的时候就越痛苦。