Addins and CustomUI, OnAction to only run Subs in book?

[KayTannee]

Hi,


I'm having a bit of issues with a few addins that we have built. When a user opens the same addin but of different versions, so they both have the same 'OnAction' sub name that they're trying to call. Then it will only call one of them.

This makes sense to me if the sub is public, it finds the first sub named that thing and runs it on click.

But I can't find any way of getting it to run OnAction only for subs within the book that the buttons belong to. No matter what I have tried, the first addin open takes priority and any subsequent duplicate addins opened, will add a menu to the ribbon, but will run the code from first opened addin.

Even the below, which as far as I'm aware should make the code in the first book invisible to the others, doesn't work and both ribbons will only work off first set.

In ThisWorkbook module

Private Sub RibbonControls(ByVal control As IRibbonControl)
    .... stuff...
end sub

and in Xml

<button onAction="ThisWorkbook.RibbonControls">

I've tried putting it in a standard module, not declaring the module etc. But nothing seems to stop the behavior.

Anyone come across this and know a way around it? It's really frustrating.

[SamT]

Why are you allowing Users to have multiple versions of the same AddIn?

See SetupUtility and UpdateAnAddin on https://www.jkp-ads.com/Download.asp

And see: https://www.jkp-ads.com/Articles/UpdateAnAddin.asp (link from UpdateAnAddin)
I
If you must allow Multiples, and your AddIns have the same name, except for version numbers, then you might be able to look at all AddIns, compare Version numbers, then use Compiler Directives to avoid even Compiling older AddIns.

A real Expert on AddIns may be along shortly to give you a real answer.

[KayTannee]

Why are you allowing Users to have multiple versions of the same AddIn?

See SetupUtility and UpdateAnAddin on https://www.jkp-ads.com/Download.asp

And see: https://www.jkp-ads.com/Articles/UpdateAnAddin.asp (link from UpdateAnAddin)
I
If you must allow Multiples, and your AddIns have the same name, except for version numbers, then you might be able to look at all AddIns, compare Version numbers, then use Compiler Directives to avoid even Compiling older AddIns.

A real Expert on AddIns may be along shortly to give you a real answer.

Thank you, I'll have a read of those. Your right in assuming a lot of this is to do with upgrading of addins.

However initially I was having the issue because a bunch of addins were calling the same 2 subs, because I just had used generic names for the subs. One for controlling clicks, and one for controlling if button Inactive/Active. Usually meant that opening a 2nd addin would just result in all the buttons being inactive because they wouldn't be on the list of ID's to enable in the first opened addins sub. Obviously the easy fix to this is just don't use a generic name for the routines.

Which just leaves me with upgrading addins. I've written a function for enabling an addin to permanently enable and also some code to disable and replace it with the new version. But all this is triggered by a button on the ribbon, so trying to enable the 2nd addin runs the code of the first. Guessing there's some work around, (thinking might just do an on open event and if triggered to run, all open addins fight it out for whose got the highest version).

Doesn't make a whole lot of sense though, seems counter intuitive that a 2nd addin can see a private sub. Hoping there's some special tag can use in the XML that says 'SeriouslyActuallyThisWorkbook.SubRoutine'

[Andy Pope]

You could try adding the addin filename.

onAction="Test1.xlam!Button1_onAction"/>

[SamT]

Kay,

I'm a little confused, (always, but more so right now...) Most AddIns are never visible to the user, but it sounds like yours' are actually used as workbooks the user interacts with... "When a user opens the same addin but of different versions,"

Most AddIns are designed to provide added functionality to every workbook the User opens and the AddIn itself stays in the background of Excel. They are made to open with the Excel Application every time it opens, with or without clicking and opening some Excel File. THe only clue the User Has is that her Excel and VBA menus and/or Menu Actions are not the Stock Microsoft Menus and/or Actions.



What you are (almost) describing sounds more like a Template, ie a standalone workbook that has added or custom functionality.

Combining the uses of an AddIn and a Template sounds like a path to failure to me. Yes, I know there are thousands, if not millions, of custom ways to use Excel. but still...

Sam