Recently I have noticed a few add-ins that lock customization on the MenuBar object after the add-in has made its changes, i.e. adding a custom menu. There are valid reasons for using this functionality but you also have to consider the impact to other add-ins that may be installed.
Example:
menuBar.Protection = MsoBarProtection.msoBarNoCustomize
If you are setting the Protection property on the MenuBar object you are preventing the user from being able to make modifications to the entire MenuBar object. This will protect your custom menu but it will also prevent any other add-ins from making changes to the MenuBar object.
If another add-in attempts to customize the CommandBars after this property is set the add-in will receive the following exception, which is not easily interpreted as a protection issue…
Error HRESULT E_FAIL has been returned from a call to a COM component.
Best Practices
1. Do not set the Protection property of the MenuBar object unless it is absolutely necessary. Rather than setting this property add the additional logic to manage your CommandBar objects. For example, check to see if your UI changes exist and if not simply add them back. I typically do this when my add-in is first loaded.
2. I started adding the following code to all of my add-ins. Before I attempt to make modifications to the CommandBar objects I check the Protection property and reset it to msoBarNoCustomize before attempting to make my changes. This ensures that my add-in is able to make changes to the CommandBar objects.
... CommandBars commandBars = Globals.ThisAddIn.Application.CommandBars as CommandBars; CommandBar menuBar = commandBars["Menu Bar"] as CommandBar; if ((menuBar.Protection & MsoBarProtection.msoBarNoCustomize) == MsoBarProtection.msoBarNoCustomize) { // make sure we can always add out UI menuBar.Protection = MsoBarProtection.msoBarNoProtection; } ...