将现有VBA引用的位置从C:\ Windows\system32 \更改为共享驱动器

Question

我已经尝试了一段时间来获取一个外部加载的参考文件无济于事.

具体来说,我正在尝试加载"Microsoft日期和时间选择控件6.0(SP4)",它通常位于C:\ Windows\System32\MSCOMCT2.OCX

但是,运行包含此元素的宏的某些人在他们的PC上没有"MSCOMCT2.OCX"文件,所以我想我会将MSCOMCT2.OCX移动到共享位置并引用代码来使用共享代码(所以每个人都可以访问它)

我想这样做,但是当我试图加载从不同的位置以"浏览"的引用也没有加载它 - 因为我已经有了,在C:..

所以我想好了......我将从C:\中删除文件,所以我只能引用共享文件. - 所以我删除了它.所以我再次打开工作簿并查看引用 - 我无法找到"Microsotft Windows Common Controls-2.6.0(SP4)" - 太棒了!然后我继续使用共享驱动器中的Browse手动添加它.然而,当我这样做时,会添加2个"Microsotft Windows Common Controls-2.6.0(SP4)"的参考 - 其中1个来自C:\(不存在),1个来自共享驱动器.

始终自动选择C:\中的一个.如果我尝试禁用C:\中的那个并从共享驱动器启用它,它会自动更改回按OK时的状态.如果我尝试启用两者 - 它表示重复的引用并仅保留C:\中的一个

所以..有没有人知道如何摆脱列表中的C:\引用,所以它不会被加载？显然删除文件本身不起作用.最终我的目标是让没有C:\ Windows\System32\MSCOMCT2.OCX文件的人能够使用我的日期选择器工具.

非常感谢!

Answer 1

ActiveX控件重新引用始终基于GUID.VB IDE会显示您计算机上注册表中列出的文件的当前位置,这是一种礼貌,但它的含义并不重要.控件将从用户计算机上注册的任何位置加载.

这是关键:控件必须在用户的计算机上注册.

我必须强烈反对你做你想做的事情.您可能能够编制一个从网络位置加载DLL的方法,但它没有比使用Right Thing(TM)和许多问题更有优势.正确的事情就是,如果你需要这种控制,你必须像你的其他人那样在应用程序中分发和注册它.你真的应该把它安装在它的推荐位置(System32); 不在网络上.

以下是可能出现问题的快速示例:您为用户提供了应用程序,并且可以像您希望的那样使用网络上的控件.然后,用户安装另一个恰好需要相同控件的应用程序.该应用程序的安装程序发现控件已在用户的计算机上注册,因此它不会尝试再次添加它.除非在用户未连接到网络时使用此特定应用程序.现在你刚破坏别人的程序.

VB/VBA架构从未打算支持XCOPY部署.我知道这很痛苦,当你只是试图部署一个"宏"时,这些额外的步骤非常不方便.可悲的是,这是野兽的本性.对不起