I have two workbooks each in its own instance. One workbook opens the other and needs to load a COM addin. The problem is the addin is not being loaded. Well, it is checked in the addins and load behavior is "load at startup", but the ribbon (and functionality) is not present.

However, when I active use the connect statement below inside the workbook open event AND open the workbook myself everything loads as desired. When the original workbook opens the workbook with this same connect in the open event, nothing happens.

Application.COMAddIns("MyStuff.Addin.1").Connect = True

How can I get the first workbook to successfully open and connect/activate/load this COM addin in the second workbook? I also tried changing the default COM load behavior to always load---same thing happens. Appears checked and loaded but no ribbon or functionality.

I have two workbooks each in its own instance. One workbook opens the
other and needs to load a COM addin. The problem is the addin is not
being loaded. Well, it is checked in the addins and load behavior is
"load at startup", but the ribbon (and functionality) is not present.

However, when I active use the connect statement below inside the
workbook open event AND open the workbook myself everything loads as
desired. When the original workbook opens the workbook with this same
connect in the open event, nothing happens.

Application.COMAddIns("MyStuff.Addin.1").Connect = True

How can I get the first workbook to successfully open and
connect/activate/load this COM addin in the second workbook? I also
tried changing the default COM load behavior to always load---same
thing happens. Appears checked and loaded but no ribbon or
functionality.

By default, automated instances don't load addins nor enforce macro
security!

The connection of a COMAddin is always to the instance it's loaded
into. Thus each instance must load the COMAddin. If your 1st instance
automates the 2nd then no addins are loaded in the automated instance
unless the COMAddin is registered under HKLM, not HKCU. If your 1st
instance is also automated, then it also needs to load the COMAddin.

Just because the addin is checked, it doesn't mean it's loaded in an
automated instance. Try toggling .Connect False/True. If that doesn't
work then maybe the COMAddin doesn't support multiple instances of
itself.

Though 'Best Practice' encourages COMAddins be registered under HKCU,
not all developers follow 'Best Practices' in order to 'force' their
COMAddins to always install/load!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

Hi, Garry. The addin is under HKCU. I'd already tried toggling .connect but get the same behavior---shows up in the addins checked and loaded. I run the same workbook on another machine (my windows 7 VM), and it works perfectly. The original workbook initiates a new excel session, opens WB, and loads COM addin. For some reason, this is not what happens at work where Excel in on a windows server. Registry appears to be consistent between the VM and server (HKCU).




On Wednesday, February 11, 2015 at 11:44:04 PM UTC-8, GS wrote:
I have two workbooks each in its own instance. One workbook opens the
other and needs to load a COM addin. The problem is the addin is not
being loaded. Well, it is checked in the addins and load behavior is
"load at startup", but the ribbon (and functionality) is not present.

However, when I active use the connect statement below inside the
workbook open event AND open the workbook myself everything loads as
desired. When the original workbook opens the workbook with this same
connect in the open event, nothing happens.

Application.COMAddIns("MyStuff.Addin.1").Connect = True

How can I get the first workbook to successfully open and
connect/activate/load this COM addin in the second workbook? I also
tried changing the default COM load behavior to always load---same
thing happens. Appears checked and loaded but no ribbon or
functionality.

By default, automated instances don't load addins nor enforce macro
security!

The connection of a COMAddin is always to the instance it's loaded
into. Thus each instance must load the COMAddin. If your 1st instance
automates the 2nd then no addins are loaded in the automated instance
unless the COMAddin is registered under HKLM, not HKCU. If your 1st
instance is also automated, then it also needs to load the COMAddin.

Just because the addin is checked, it doesn't mean it's loaded in an
automated instance. Try toggling .Connect False/True. If that doesn't
work then maybe the COMAddin doesn't support multiple instances of
itself.

Though 'Best Practice' encourages COMAddins be registered under HKCU,
not all developers follow 'Best Practices' in order to 'force' their
COMAddins to always install/load!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

Hi, Garry. The addin is under HKCU. I'd already tried toggling
.connect but get the same behavior---shows up in the addins checked
and loaded. I run the same workbook on another machine (my windows
7 VM), and it works perfectly. The original workbook initiates a
new excel session, opens WB, and loads COM addin. For some reason,
this is not what happens at work where Excel in on a windows
server. Registry appears to be consistent between the VM and server
(HKCU).

Unfortunately, behavior on your server may be dictated by GroupPolicy
there. VM and/or local should have same behavior so long as the
COMAddin is installed/registered, respectively. That means the local
reg isn't valid for the VM (AFAIK).

Another point is that you need to set a fully qualified object ref to
the COMAddin to access it in your project[s], otherwise COMAddins have
to provide menus to access methods via the UI. In 2007 and later the
menus are provided via xml for the Ribbon, or via custom
commandbars/menus for use on the Addins tab. The latter works for both
early/late versions, but xml is needed to put menus/tabs on the Ribbon.

Finally, if you have menus created by your COMAddin then if they don't
fire their respective OnAction you should at least get a notification
about COM failure or the like.

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

Thanks for the detailed response, Garry. Just fyi, the COM I'm trying to load isn't one I created---it's a 3rd party COM that has functionality I use which is why I need it loaded. Guess I've kinda hit a wall on the server---maybe there is some group policy that affects the addin load behavior. Unfortunate since it puts a stop to my automation.

On Thursday, February 12, 2015 at 11:44:53 AM UTC-8, GS wrote:
Hi, Garry. The addin is under HKCU. I'd already tried toggling
.connect but get the same behavior---shows up in the addins checked
and loaded. I run the same workbook on another machine (my windows
7 VM), and it works perfectly. The original workbook initiates a
new excel session, opens WB, and loads COM addin. For some reason,
this is not what happens at work where Excel in on a windows
server. Registry appears to be consistent between the VM and server
(HKCU).

Unfortunately, behavior on your server may be dictated by GroupPolicy
there. VM and/or local should have same behavior so long as the
COMAddin is installed/registered, respectively. That means the local
reg isn't valid for the VM (AFAIK).

Another point is that you need to set a fully qualified object ref to
the COMAddin to access it in your project[s], otherwise COMAddins have
to provide menus to access methods via the UI. In 2007 and later the
menus are provided via xml for the Ribbon, or via custom
commandbars/menus for use on the Addins tab. The latter works for both
early/late versions, but xml is needed to put menus/tabs on the Ribbon.

Finally, if you have menus created by your COMAddin then if they don't
fire their respective OnAction you should at least get a notification
about COM failure or the like.

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

Just an afterthught...

The COMAddin's xml (IRibbonExtensibility interface) for xl2007 likely
doesn't work for xl2010 or later since the Ribbon structure was changed
in xl2010. I can't verify this because I stopped using COMAddins some
years back, but you might want to try updating to a newer version.

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion