• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 359
  • Last Modified:

Custom Menus and Toolbars Keep Multiplying

In an addin template in Word 2002, I've written code (Sub BuildUI)  to create a couple of custom menus and a custom toolbar with a couple of buttons. I've also written the code to delete the menus and toolbar (Sub DeleteUI). The menus, commands, and toolbar buttons are deleted with the code snippet below; the toolbar by name. (This method ensures that the controls are also deleted if the user has moved them.)

The BuildUI procedure is called from AutoExec; DeleteUI from AutoExit. DeleteUI is also called at the start of BuildUI to ensure that the custom UI is absent before it is created. I've verified through MsgBoxes that the code does run.

This method has always worked for any solution I've created. But in the environment I'm working in now, things are odd.

When I launch Word with the addin installed, Word appears with multiple copies of the toolbar. These are immediately deleted, and the custom UI recreated, but next time I launch Word, yet another copy of the toolbar is present before they are all deleted again. And so on; every time I launch Word, one more copy of the toolbar is present before it's deleted by my code.

I have verified that the toolbar(s) is/are not embedded in Normal, nor are they present in my addin. I have also verified that the CustomizationContext for my code is Normal.

Obviously, I don't want this growing number of toolbars when my users launch Word. Even though they are immediately deleted, it looks sloppy, and I'm concerned that there will come a point when Word can no longer handle this multitude of identical toolbars.
Dim ctls As Controls, ctl As Control
Set ctls = Application.CommandBars.FindControls(Tag:=MyTag)
'Controls get MyTag as tag on creation
If Not ctls Is Nothing Then 'FindControls returns Nothing if no controls with that tag
   For Each ctl In ctls
   Next ctl
End If

Open in new window

  • 3
1 Solution
I think I would delete them a little differently. If the Command Bar and controls are not there, then you can catch the Error and code around it. It'll through an Error 5 if the controls are not there to delete, but you can either catch that inline or build an Error Handler that will Resume Next.

Dawn Bleuel
Word MVP
With Application.CommandBars("Menu Bar")
End With

Open in new window

FlorisMKAuthor Commented:
Thanks for your reaction, Dawn.

There are two objections to your approach in my situation:

1. I want to delete my custom controls wherever they may have ended up, even if the user has (accidentally) dragged them from the menu bar to somewhere else in the CommandBars collection. So that precludes explicitly referring to the Menu Bar.

2. I don't want to refer to each control by name, because it's not a robust solution and doesn't deal properly with multiple copies of the control; that's why I use the .Tag property to identify all my custom controls. Using the Tag opens up the possibility of using FindControls to delete all of them.
FlorisMKAuthor Commented:
The answer turns out to be that Normal.dot is unloaded before my own addin. Therefore, the code deleting the custom UI does not affect the changes in Normal.
FlorisMKAuthor Commented:
To resolve the issue and manage the toolbars more smoothly, I now use the following code:

Public Sub CreateCustomUI()
   Dim oContext As Object
   ' Store the current CustomizationContext and change it to refer
   ' to the addin template. This ensures that Normal.dot isn't
   ' contaminated with multiple copies of the UI
   Set oContext = Application.CustomizationContext
   Application.CustomizationContext = ThisDocument
   ' Delete any remaining custom UI and rebuild the custom UI 
   ' from scratch. It is essential that the UI is NOT created 
   ' with the Temporary parameter! Otherwise, the custom UI may
   ' disappear when switching between documents!
   Call DeleteCustomUI()
   Call BuildCustomUI()
   ' Make sure that the user isn't prompted to save the addin
   ThisDocument.Saved = True
   ' Restore the CustomizationContext to what it was before we
   ' started.
   Application.CustomizationContext = oContext
End Sub

Open in new window

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now