Temporary Toolbars

[Ed]

I want to create a toolbar, but I don't want to affect the normal (or any
other global) template. By that, I mean I don't want, upon exit, the normal
(or other) template to save (or ask to save). I thought that by creating a
temporary toolbar, I could accomplish this. Here is the code

Set myBar = CommandBars.Add(name:="Custom", Position:=msoBarFloating,
temporary:=True)

But, that does not do the 'trick.' When I exit Word, normal.dot saves.

Is there any way to create a truly temporary toolbar in such a way that
normal.dot doesn't think it was modified? (I did try CustomizationContext
and set the reference to another global template, but when I exited Word,
Word asked if I wanted to save the context template. I need a 'clean' exit,
if at all possible.) Thanks. (I was, of course, hoping that a truly
temporary toolbar would not cause Word to think anything was modified.)

Ed in Virginia

 

[Jay Freedman]

At the end of the document, set the .Saved property of the template to
True. For example, if the customization context for the toolbar was
Normal.dot, you could write

NormalTemplate.Saved = True

That lies to Word and tells it that the template isn't dirty.

But you have to be careful with this, because the user just might have
made some other change to Normal.dot that they do want to save, and
this would throw it all away. Better to use another global template as
the customization context for the toolbar, and tell that one that it's
"saved".

--
Regards,
Jay Freedman
Microsoft Word MVP
Email cannot be acknowledged; please post all follow-ups to the
newsgroup so all may benefit.

 

[Jean-Guy Marcil]

Jay Freedman was telling us:
Jay Freedman nous racontait que :

At the end of the document, set the .Saved property of the template to
True. For example, if the customization context for the toolbar was
Normal.dot, you could write

NormalTemplate.Saved = True

That lies to Word and tells it that the template isn't dirty.

But you have to be careful with this, because the user just might have
made some other change to Normal.dot that they do want to save, and
this would throw it all away. Better to use another global template as
the customization context for the toolbar, and tell that one that it's
"saved".

There shouldn't be any problem with user modifications if

NormalTemplate.Saved = True

is placed immediately after the code that creates the toolbar,

This way, any other changes that would change the state of
NormalTemplate.Saved
would be due to user interaction, and therefore the questions to save the
template perfectly legitimate.

Right? Did I miss something?

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

 

[Jonathan West]

Jay Freedman was telling us:
Jay Freedman nous racontait que :


There shouldn't be any problem with user modifications if

NormalTemplate.Saved = True

is placed immediately after the code that creates the toolbar,

This way, any other changes that would change the state of
NormalTemplate.Saved
would be due to user interaction, and therefore the questions to save the
template perfectly legitimate.

Right? Did I miss something?

Yes, you missed something. If the user makes other changes, those changes
*and* the changes to the toolbar are all saved.

In such circumstances, the changes should be made with the customization
context set to some other template, and that template's Saved property is
set to true. Since the template is unlikely to be accidentally or
deliberately modified by the user, you are reasonably safe from accidental
modification.

 

[Jean-Guy Marcil]

Jonathan West was telling us:
Jonathan West nous racontait que :

Yes, you missed something. If the user makes other changes, those
changes *and* the changes to the toolbar are all saved.

DUH! Give me another donut!

Too early in the morning to read the groups, I guess!

Now that I think about it, I wrote some code a while back to avoid such a
thing. I was making changes to a toolbar on the fly (depending on user
actions while editing the document content), but the user was also creating
Autotext entries in the same template.
So I created some routines to check the status of the Template.Saved status
before making my changes, then I made my changes and restored the Saved
status to its initial value.
Then, when closing the document, since I was tracking the value of the Saved
property every time I made a change, I knew if the user needed to be
bothered with the "Do you want to save your template" question.
I used doc variables to save the flags needed to reconstruct the toolbar
when opening the document (doc variables saved with the document, not the
template), this way, along with a Document_Change event, many documents
opened simultaneously could display a different toolbar when going from one
document to the other, even though they were all based on the same template.

This is the second time in a few weeks I forget about this... It will
eventually sink in!

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

 

[Ed]

Thanks, Jay, Jonathan ahd Jean-Guy,

I understand the challenge. You laid it out very nicely for me in the
discussion. I just wish that the creation of a simple, temporary, toolbar
didn't create these problems in the first place. I do have another global
template to which I can attach the toolbar, so I will work on the
customization context feature and switch to that template. I hadn't thought
of that. Maybe in 2007 it won't be necessary?

Ed (in virginia)

 

[Jean-Guy Marcil]

Ed was telling us:
Ed nous racontait que :

template. I hadn't thought of that. Maybe in 2007 it won't be
necessary?

For some comments on this, see the thread by your namesake titled:
Will macros creating new menus break with Ribbon?
on June 5th (in this same NG).

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

 

[EscarHolmez]

I am doing something similar -- my add-in adds a menu with
CustomizationContext set to the calling template (not Normal.dot) and
then deletes the menu when the template closes.

Earlier I tried creating a temporary menu, but that did not work well
for me -- my menu disappeared if some other add-in or the user changed
the customization context. Someone said that creating the menu as
permanent (not temporary) and then deleting it was the best approach.
Now I can't find that reference.

The problem I have now is that each time a template is opened and
closed in Word 2003, its file size bloats by 10-30 kB. This happens
even if I make no changes to the template (other than the menu
add-delete done by the VBA code). Microsoft knows that Normal.dot
bloats in Word 2003 when menus are added to and deleted from it:
http://support.microsoft.com/?scid=kb;en-us;873017&spid=2530&sid=63#top

Unfortunately, Microsoft's workaround is to set the
CustomizationContext to the custom template, shifting the problem to
your template! I let them know I wanted a real solution. Earlier
threads in this Google Group also discussed the problem:

http://groups.google.com.au/group/m...+file+size+word&rnum=1&hl=en#d787ac2159b92079

http://groups.google.com.au/group/m...elete+file+size&rnum=1&hl=en#399375667d146634

What we need is either for Microsoft to fix Word or a method to
completely remove a CommandBar when deleted.

Reminds me of a problem I had a couple of years ago: Word leaves old
bookmarks in a document when it rebuilds a Table of Contents. After
rebuilding the TOC hundreds of times, the document gets clogged with
hidden, unused bookmarks and starts to have problems. To fix that
problem I added code that removes the unused bookmarks to my routine to
update the TOC (and all other fields in the document, including headers
and footers).

Does anyone know of a way to identify and completely delete unused
CommandBars?

 

[Jean-Guy Marcil]

(e-mail address removed) was telling us:
(e-mail address removed) nous racontait que :

I am doing something similar -- my add-in adds a menu with
CustomizationContext set to the calling template (not Normal.dot) and
then deletes the menu when the template closes.

Earlier I tried creating a temporary menu, but that did not work well
for me -- my menu disappeared if some other add-in or the user changed
the customization context. Someone said that creating the menu as
permanent (not temporary) and then deleting it was the best approach.
Now I can't find that reference.

The problem I have now is that each time a template is opened and
closed in Word 2003, its file size bloats by 10-30 kB. This happens
even if I make no changes to the template (other than the menu
add-delete done by the VBA code). Microsoft knows that Normal.dot
bloats in Word 2003 when menus are added to and deleted from it:
http://support.microsoft.com/?scid=kb;en-us;873017&spid=2530&sid=63#top

Unfortunately, Microsoft's workaround is to set the
CustomizationContext to the custom template, shifting the problem to
your template! I let them know I wanted a real solution. Earlier
threads in this Google Group also discussed the problem:

http://groups.google.com.au/group/m...+file+size+word&rnum=1&hl=en#d787ac2159b92079

http://groups.google.com.au/group/m...elete+file+size&rnum=1&hl=en#399375667d146634

What we need is either for Microsoft to fix Word or a method to
completely remove a CommandBar when deleted.

Reminds me of a problem I had a couple of years ago: Word leaves old
bookmarks in a document when it rebuilds a Table of Contents. After
rebuilding the TOC hundreds of times, the document gets clogged with
hidden, unused bookmarks and starts to have problems. To fix that
problem I added code that removes the unused bookmarks to my routine
to update the TOC (and all other fields in the document, including
headers and footers).

Does anyone know of a way to identify and completely delete unused
CommandBars?

If adding/deleting a toolbar every time you create/open a document based on
a template creates problems, have you tried hiding/unhiding instead?

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

 

[EscarHolmez]

The reason for creating a fresh menu each time is to deal with other
nasty add-ins that indiscriminantly wipe out menus from other programs.
Adobe Acrobat Writer (not Reader) is the main culprit my clients have.

I haven't tried hiding the menu, but my guess is that Acrobat would
still kill it.

Putting my menu just to the left of Word's 'Help' menu does sometimes
avoid conflicts, but I would prefer to have my menu after all of Word's
menus.

My understanding is that creating and then deleting a custom menu is
"best practice". At this point I am ready to go back to leaving the
menu in my template and only creating it if it disappears.