It's common for an Office add-in to put some custom menu items or toolbar buttons in the UI of the hosting application. The method to call to do this is CommandBars.Add. It is also typical that you'd like those customizations to appear so long as the add-in gets loaded, but not appear if it doesn't. If your add-in gets uninstalled, for example, you clearly don't want left-over customizations littering the application. For this reason, the Add method's final parameter is a boolean that indicates whether a particular added control should be added temporarily. The documentation describes the parameter like this:
- Optional Object. True to make the new control temporary. Temporary controls are automatically deleted when the container application is closed. The default value is False.
This looks perfect. You can add the customizations at startup, and they'll be gone at shutdown... except that it doesn't work in Word.\
There is a support articlethat acknowledges this, but it is not a bug in Word. Instead, as I read the article, it is functionality not deemed worthy of Word, given its vastly superior customization capabilities.
By default, Word adds any customizations to the Normal.dot template, which causes a couple of problems:
I've tried a few different approaches to get the temporary functionality in Word similar to how it is documented (and implemented by other Office applications like Excel and PowerPoint). One approach is to add all the customizations at add-in startup, and (since the temporary flag doesn't do it for you) remove them all again at add-in shutdown. This mostly works, but you have to be kind of careful. If the application crashed for some reason, missing the add-in shutdown step, you need to check for your customizations before adding them again or you'll get duplicates. Also, Normal.dot needs saving every time the application exits. It's not a huge problem -- the little progress bar goes pretty fast -- but it is slightly annoying.
Among several others that I tried, the approach that I finally settled on takes advantage of the Word application object's CustomizationContext property, which lets you send CommandBar customizations to a template other than Normal.dot.
Here are the basic steps:
The last step is the key. Since Word thinks that the template isn't dirty, it doesn't save it, and any customizations it contained will be automatically discarded when the application exits. If your add-in doesn't get loaded ever again, the customization template will never be loaded, and would be empty even if it was.
I've found this approach to be simple; you don't have to check for existing customizations at startup or remove anything at shutdown. No templates need to be saved, and I stopped getting random bug reports of lingering customizations or Normal.dot save prompts.