Application.CustomizationContext = Application.Customization context is removing my doc's toolbars

[Mark Rubin]

Hi,

If I create a new document based on a template with toolbars, and then
execute the following line of code, my toolbars disappear:
Application.CustomizationContext = Application.CustomizationContext

I've tried this with Word 97-2003. I simply opened a document, added
a custom toolbar, saved the document as a template, closed Word and
restarted it, created a new document based on my template (my toolbar
appears, as you'd expect), and then executed this line of code in VBA.

Originally this was found when I had code that cached the original
Application.CustomizationContext, loaded an addin, set the
CustomizationContext to my addin, and then tried to set the
Application.CustomizationContext back to its original value. So then
I simplified my coding logic and came up with this.

Does anyone know what's going on here? Perhaps I'm not understanding
the CustomizationContext too well, or global templates, or something
like that--I'm relatively green at Word automation. Still, it seems
odd to me that this code should have such a side-effect.

Thanks for any help.

-- Mark

 

[Chad DeMeyer]

Mark,

This does seem to be an inexplicable result and a bug, and I don't know
what's going on either. But it occurs to me that it shouldn't be necessary
to restore an original customization context. If any other customizations
are made by code, the customization context should be explicitly set prior
to making each customization, as you did in your code, so it doesn't matter
what the context was set to after the previous customization. And if a
customization is made through the UI, I'm fairly sure that the UI makes its
own judgement about what the default context should be when the
customization dialogs are displayed, based on properties of the active
document.

Regards,
Chad

 

[Mark Rubin]

Hi, Chad,

That's an interesting suggestion. Trying to be good programmers, we
were instinctively trying to restore as much as we could to its
original state when we were done. But in this particular case, you're
right that it would seem that we shouldn't really need to. I guess
the worry is this. This piece is part of a larger application we've
built that our clients will install; they can have all sorts of other
code and templates installed they've created, and our experience is
that their own templates and code is usually not written with safety
in mind; so we need to make sure our stuff will play well with their
stuff, and you can't always count on them to play fair! But maybe in
this particular case, it's so absurd to have your code assume a
customization context without having set it, that we're pretty safe.
I'm just worried that someone will have written code to do that, and
we'll get the blame. But I will give it some thought, and I
appreciate the suggestion.

M

 

[Chad DeMeyer]

Mark,

My curiosity was piqued further, so I did some more research. I did a quick
test of WordBasic.ToolsCustomizeMenus, and it seems to make the changes
without changing the customization context. Check out
http://search.microsoft.com/search/results.aspx?qu=ToolsCustomizeMenus&View=msdn&st=b&c=4&s=1&swc=4.

Regards,
Chad

 

[Mark Rubin]

Very interesting! I didn't know about that WordBasic object. One of
my fellow engineers contacted Microsoft about the bug, and they've
confirmed it as a bug that they had filed internally but had not
announced publicly. We're still going back and forth with them, so
we'll run by them your suggestion to see what they think (if they can
see if there are some unintended side-effects). Thanks a lot for the
help.

-- Mark