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