Enr*_*ico 10 excel vba excel-addins powerquery
该方案是Windows Server 2012 R2,64位; Excel 2010,32位.许多用户,只有其中几个拥有管理权限.我从内置管理员安装了Power Query.没有询问任何内容,为所有用户安装了加载项; 我的意思是它的设置可以在HKLM下的注册表项中找到,而不是HKCU.
关键是
HKEY_LOCAL_MACHINE -> SOFTWARE -> Wow6432Node -> Microsoft -> Office -> Excel -> AddIns -> Microsoft.Mashup.Client.Excel
而相关的价值是
LoadBehavior (REG_DWORD)
现在只有少数用户真的需要Power Query.每次启动Excel时,我都不希望它为每个人加载.我为LoadBehavior值尝试了一些不同的设置(请参阅此链接).我找到了以下内容:
软件 - > Microsoft - > Office - > Excel - > Addins - > -Microsoft.Mashup.Client.Excel
这一切似乎都很好.现在问题是我需要从VBA过程调用一些Power Query操作.如果已加载Power Query,则一切正常.但如果未加载,即使使用"按需加载"设置,操作也会失败.为了加载Power Query,必须按下Excel GUI上的某个按钮,该按钮调用Power Query操作.
我发现VBA中有一个加载项对象的属性,它指示加载项是否已加载,并且可以设置为从VBA加载或卸载加载项.它是:
Application.COMAddIns.Item("Microsoft.Mashup.Client.Excel").Connect
如果是True,则加载加载项,如果加载,则加载加载False项.
现在应该可以通过将此属性设置为True来加载加载项.但是,在我的方案中情况并非如此:结果是错误(80004005).这似乎是与没有管理权限的用户相关的问题.查看此页面 - 此行为被视为错误.
我将在稍后尝试的最后一个想法是完全删除HKLM下的密钥中的LoadBehavior.我已经检查过这会阻止用户看到加载项,除非创建了特定于用户的密钥,在这种情况下,用户可以自动设置加载项加载行为.我将看到在这种情况下从VBA请求加载时会发生什么.
同时,我很感激任何想法来解决这个问题:Power Query没有正常加载,可能是按需提供所有用户,从VBA自动加载(至少对于某些用户),所有这些都无需手动添加用户所有用户的特定密钥.可以为少数用户添加此密钥,即实际需要Power Query的用户.
编辑
删除或重命名HKLM下的密钥中的LoadBehavior值.然后,只有在HKCU下具有特定密钥的用户才能看到Power Query.如果在此键中,LoadBehavior的值设置为3(或2),则默认情况下加载加载项(分别未加载).更改.Connect属性的VBA指令工作正常; 它将LoadBehavior切换为3(True)和2(False).幸运的是,我还可以在注册表中设置LoadBehavior = 9(在HKCU下),并且.Connect属性仍然是可写的.在这种情况下,当为此属性分配一个True值时,加载加载项,但LoadBehavior值仍然保持在9,这样在关闭并重新打开Excel时,加载项被卸载,设置为"加载"需求",可以从VBA加载.
这正是我所寻找的行为; 唯一需要注意的是,需要为需要Power Query的所有用户创建密钥.因为在我的情况下,他们可能只用一只手指,这个解决方案是可以接受的.
我仍然很想知道是否有人提出任何更好的解决方案.
小智 1
您是否考虑过使用 powershell 脚本来相应地更新每个用户的注册表项?下面的例子有点复杂,第111行有一个循环,你需要为很多用户设置它。
https://daniel.streefkerkonline.com/2014/04/09/re-enable-microsoft-office-add-ins-with-powershell/
我的另一个建议是您不应在 Excel 2010 中使用 VBA 来调用任何与 PowerQuery 相关的内容。鉴于它是一个加载项,我认为它没有包含在 Excel 2010 的服务协议中。Excel 2010 中不完全支持或调试 VBA 与 PowerQuery 的交互。我注意到几个补丁完全破坏了 PowerQuery 中的 GUI。升级到 Excel 2013 或 2016 即可解决。
当使用 Excel 2016 VBA 编辑器与 PowerQuery 交互时,宏代码很难调试和运行,而且其参考文献记录很少。显示错误更稳定,而不仅仅是崩溃,但解决编译器发现的错误非常具有挑战性。
| 归档时间: |
|
| 查看次数: |
639 次 |
| 最近记录: |