Like John said, it sounds very confusing. Also, in every version of Excel where I have tried to have 2 add-ins communicate with each other, sooner or later I have got an error along the lines of “the callee has disconnected and cannot be reached.”

My approach to multiple add-ins with overlapping menus is the following. A table contains information about all the menus needed by a particular add-in. This table can be an Excel range or an array. The latter is used for Word and PowerPoint add-ins.

I have designated one add-in as the “master” for code that is common across all my add-ins. This code includes commandbar, help, version, registration and website handling. If I have to make any changes to those routines, the changes always start with this one add-in. The commandbar, i.e., menu, handler is all in one class module. Each add-in’s Open and BeforeClose event routines simply create an instance of the menu class and call the appropriate method (CreateMenus or DeleteMenus) with the appropriate argument(s).

[I've had to add two additional modules (one a form, the other a standard module) to get add-ins to play nice across the 2003-2007 divide.]

CreateMenus goes through every row in the table passed to it as an argument. Each row contains information about one menu item, including the menu hierarchy, which includes the following: Application commandbar name, (optional) name of the ‘top level’ menu within the application commandbar, (optional) name of ‘pop up’ submenu under the ‘top level’ menu, and the menu item itself.

The code adds any menus / submenus as needed until it can create the menu item itself. By making the top level menu optional, the same code can create items in context menus (such as the Cell commandbar that is accessed by a right click on a cell).

The DeleteMenus uses the same table as the CreateMenus routine to reverse the process. It deletes the menu item. Then, if the submenu has zero children, it deletes the submenu. Then, if the ‘top level’ menu has zero children it deletes it.

Also, the menu handling code includes a mechanism whereby it creates menu items that work in an application add-in (using the OnAction property) or a COM add-in (event driven).

To create different menu setups for different clients / environments requires just a change in the entries in the table in the respective add-ins. No code changes needed.

IMO, clean, self-contained, easy to maintain, and all add-ins play nice.

Let me know if you want the password.

Keep all the related code in its own module. When you have to change it, do so in one add-in, then replace the module in the other add-ins with the modified module. Not perfect, but not too much of a bother.