Is there a bug in Word 2003's delete/update toolbar facility?

[johndavidson]

Can anyone confirm whether there is a bug in Word 2003's delete/update toolbar facility -- when done either using Tools > Organizer or programmatically? On my setup (Word 2003/ 64-bit Windows 7 etc) ...

When a toolbar containing menus (and maybe regular toolbars, too) is copied to a template, if there is an old toolbar of the same name, the old version does not get properly deleted.

When the toolbar has just been copied, it appears to be correct, for as long as Word remains open. However, when you close and reopen Word and look at the contents of the toolbar, Word has found a previous, presumably undeleted copy. In fact, the target template can be seen to gradually increase in size, as you go on trying to delete the old and add the new. This even happens with a fresh, new template document with nothing else in it, so it cannot be a corrupt template.

Sometimes, other oddities can happen such as part of the items in one menu ending up in another. Word can also crash (stops responding and needs to be killed by an external program).

It happens whether the copying of the toolbar is done in Organizer or programmatically.

On occasion, in Organizer, these multiple toolbars of the same name can actually be seen and listed. I once had 10 or 12 of the same toolbar show up, and deleted them all – but they didn’t go away. This means that there is only a one-shot chance of copying a toolbar containing menus to another template. After that, however much you try to update the toolbar in the target template, you can only read old versions. To update an already existing toolbar in a template, you must first recreate the template, copying all the items using Organizer, set any VBA references, and rename the VBA project to what it originally was. This way the toolbar and menu shortcuts still work, though all the hotkey assignments are lost.

Can anyone shed any light on what is going on?

[Frosty]

There are a host of bugs in the commandbars collection within Word 2003. I'm not sure your level of expertise, but my best practice in dealing with command bars in Word 2000/2003 has been (for years) to create my toolbars programmatically, rather than through the GUI provided by Microsoft.

From there, specifically related to popup controls (menus), it's critical to make sure you assign the .NameLocal property of the commandbar associated with the popup control. Otherwise, as you've noticed, you'll see that Word can get confused about which commandbar to show when you click the popup control, resulting in other menus showing up (or older versions of it) when you click a particular menu.

Commandbars("MyCommandBar").Delete

Can actually be run multiple times without error in some cases, even though a named item in a collection is supposed to be a unique identifier.

Even setting up my entire user interface programmatically (including custom icons), I still end up making sure I attempt to delete a commandbar 20+ times before I create it new.

Of course, you don't have to create your UI programmatically, but you do have to be very careful when creating with the GUI. And I would imagine that you'll run into issues when then copying that from one template to another (although I haven't attempted that process for a long time, once I settled on my own best practice of simply creating the entire UI programmatically).

The one exception I have to this is that I have to copy a custom toolbar containing custom icons into a template in order to use .CopyFace and .PasteFace for custom graphics.

Note, you can also assign keybindings (shortcut keys) programmatically as well.

If you are sticking with Word 2003 for awhile, I would recommend developing your UI progammatically. It will save you a lot of headaches (it has made recreating my templates from scratch much much less painful), although it will take some time to get it up and running, initially...

[johndavidson]

Thanks. That's really, really helpful, and I'm happy to know I'm not being completely stupid! My progamming expertise in VBA is limited. I cut my teeth back in the 60s & 70s writing machine code/assembly language for DEC PDP8s. Then graduated to Focal & Fortran. Then a gap before WordPerfect 5.1+ came along with a macro language, and now VBA for Word, which I've been struggling with for a couple of years or so. So basic programming concepts I understand, but the vast syntax of VBA, and all the objects, methods, properties and so on often defeat me. Then I search the www or ask friends. I'm a writer, presently overseeing an encyclopedic sort of project, and the use of macros is essential to handle all the entries and do specialist text manipulation tasks. Given that Word 2007 onwards (xml-based) runs text manipulation macros around 8 times more slowly than 2003 (and some of our macros can run for several minutes, even in Word 2003), and I don't like all the ribbon clutter, we're staying with Word 2003 for the time being.

What I'm trying to achieve at the moment is a way for a collection of odds-and-ends macros to be available to other contributors to the project. Some specific-task macros (written by others) are all neatly arranged in their own templates, but I had a collection of stuff that had accumulated in my Normal.dot which was not readily transportable without messing up the Normal.dot of others. It's all in its own template now, and the hotkeys are all set programmatically. I've found ways and workarounds to most things, moving towards the programmatic way, but there are still a few things I can't figure out how to do. Eg.

1. What do I need to add to this statement to make the item "begin a group"?

CommandBars("Menu Additions (in Normal.dot)").Controls(3).Copy Bar:=CommandBars("Menu Bar"), Before:=8

I think it's BeginGroup = True, but how to implement it?

2. And then, how to (programmatically) put shortcuts to macros in the right-click context menu ("Text").

3. And finally, how to make additions to the main menu bar that are present in one template show up when that template document is not actually an 'officially' open document, tho present in the ...Word/Startup folder.

I think this is possibly going off-thread here, so we may need to relocate.

[Frosty]

I don't think it's off topic... you're asking about bugs and how to address them in Word 2003 toolbars. The answers here will be useful to others, potentially. Before I get to that, I would like to address one of your points:

The idea that text manipulation in an .xml file (.docx) is slower than text manipulation in a binary file format (.doc) is not something I've found to be true. In fact, quite the opposite. In general, processing the new file formats is faster. So although I believe your statement for your environment, I wouldn't necessarily agree that it is universally true (that Word 2010 handles programmatic string manipulation more slowly than Word 2003).

I would suspect that there is some optimizations to be gleaned from the macros you run. I have not found long macros to be appreciably slower in 2010 than in 2003 (and I specifically have some long ones I use to convert documents which involve identifying numbering schemes and a lot of text identification for the purposes of deleting and applying styles). But that decision point doesn't matter, since I'm not trying to convince you to go to 2010. I would suggest you keep an open mind that your code may be the problem (or at least, part of it), in regards to something inherent about the .xml format.

On to your questions...
1. it looks like the .Copy method as it applies to a commandbar control returns the copied control. So...


Sub Sample1()
Dim oCtrl As CommandBarControl
Set oCtrl = CommandBars("Menu Additions (in Normal.dot)").Controls(3).Copy (Bar:=CommandBars("Menu Bar"), Before:=8)
oCtrl.BeginGroup = True
End Sub

Should do it. However, I'm not a fan of this idea in general-- especially if you are copying entire menus. I think it would be better to build the menu from scratch.

2. You know the name of the commandbar... so you need to access it.

Sub Sample2()
Dim cBut as CommandBarButton
Dim cBar as CommandBar

Set cBar = CommandBars("Text")
Set cBut = cBar.Controls.Add (Type:=msoControlButton, Before:=1)
With cBut
.Caption = "Hello World"
.Style = msoButtonCaption
End With
End Sub


3. This is more a conceptual question. By default, what you're describing is exactly how it should work. i.e., you have a template with some custom toolbars in it... that template is loaded automatically as an addin because it's in the startup folder.

Then the question is-- *why* isn't it working? This is likely because of the .CustomizationContext property and the ability for templates to interact with each other in poor ways. One template might have a custom menu which is supposed to show up on the menu bar... but another template might be telling it to be hidden. This can be especially likely if you point to specific positions (like your "8" in Sample1), rather than using .FindControl.

Typically, you should be able to either delete normal.dot or reset all customizations to the Menu Bar in the Normal.dot context-- and you'll see other global addin menus start showing up.

The exception to this is that some global addins load their toolbars as temporary toolbars in the Normal.dot context-- so you can lose those as well, until you reload those addins.

In short-- there are a lot of areas to check why it's not working the way it should be:
A. Delete/Rename your existing normal.dot (that's the most likely reason your custom menu isn't showing up-- it's there, but it's being told to be hidden by something else)
B. start Word "clean" by using Start > Run > Winword /a
And then open your addin to see if your custom menu is there...

I would highly recommend you use that Sample2 subroutine as a starting point for creating all of your user interface... because the most likely scenario is that you've got a bit of a GIGO (Garbage In Garbage Out) problem as you utilize a "Copy this toolbar from A to B" methodology... rather than creating this stuff from scratch.

[fumei]

my 2 cents...I am in complete agreement with Frosty regarding copying toolbars; I have found it far better (and generally faster as you do not have to deal with precisely the issue - what heck is going on! - that you are dealing with). At least from scratch is i principle cleaner.

As for the multiple toolbars crap, yes that is a behaviour that can be traced back to to 2002. One time I finally checked and there was 23 toolbars of the same name. What the heck is THAT all about?

Again, a good reason to start fresh.

Frosty is quite correct, if a template (add-in) file is in Startup, then it is loaded and all code is available. That being said code is NOT the same thing as GUI aspects such as toolbars and menus. They can, and do, cause conflicts with elements.

Lastly, perhaps move yout templates (addins) out of Startup, and load them dynamically. It makes it easier to debug conflicts. I am not a fan of putting add-ins into Startup as I have found that it is rare that add-ins are truly required to be available ALL the time. It is so easy to load them dynamically, when required, and then unload them when NOT required.

[Frosty]

Adding stuff dynamically can be a good approach. Also, creating temporary toolbars when your addin is loaded is another step that ends up solving a lot of the history problems (multiple toolbars of the same name). I've used that with a lot of success with a global addin. It's not so great if you are also using custom graphics, but I've gone away from custom graphics more and more. There are a lot of built in graphics that can be appropriate "enough" for the functionality the macro is performing. Even 2003 has a lot of graphics. It just takes a bit of work to find out the face ids

[fumei]

yeah, custom graphics were fun when it was new, but...

[johndavidson]

Thanks v. much again to you both. I followed instructions, and all the issues are resolved. There are still things that Word is doing with its toolbars that seem to have little logic, but hey, it's working! The customization context was the issue as regards the menus not showing up on startup. I'm uncertain whether clicking the "Reset menu and toolbar usage data" button in customize, or executing the CustomizationContext = NormalTemplate did the trick.

Something that would be useful to know how to do is how to add MS or custom-supplied icons to go with the menu/toolbar items

On the matter of our text manipulation macros running slowly, I'm really pleased to hear that you think it is more of a coding problem than an issue with Word 2007 onwards. If you want to continue with this, it could be helpful to many other people out there. See eg.

http://social.msdn.microsoft.com/Forums/en-GB/worddev/thread/4a5d1400-33aa-4a0d-b30e-482f02e76f1b

And my post at:

http://www.eggheadcafe.com/community/word/67/10267673/slow-speed-of-vba-macros-written-for-word-2003-in-20072010.aspx

If you want to take this up, would you like to start a thread, something like "Word 2003 VBA macros running slowly under Word 2007+", and we can continue from there?

There a fair amount of background in my eggheadcafe post, so that's worth looking at before we start.

It could be great to have a solution to this issue. At least identifying any code that runs more slowly under Word 2007+ would be very useful, though I wonder if the issue of *.docx (=xml) files opening more slowly can be fixed other than by getting an SSD.

Thanks again.