Temporary Toolbars

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
Tue Jun 06 23:06:01 CDT 2006

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 FAQ: http://word.mvps.org
Email cannot be acknowledged; please post all follow-ups to the
newsgroup so all may benefit.

On Tue, 6 Jun 2006 23:22:10 -0400, "Ed" <ed@pathagoras.com> wrote:

>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
>

Jean-Guy
Wed Jun 07 08:31:47 CDT 2006

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
jmarcilREMOVE@CAPSsympatico.caTHISTOO
Word MVP site: http://www.word.mvps.org

Jonathan
Wed Jun 07 08:37:14 CDT 2006


"Jean-Guy Marcil" <NoSpam@LeaveMeAlone> wrote in message
news:%236zg%23ajiGHA.4140@TK2MSFTNGP03.phx.gbl...
> 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?

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.

--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup

Jean-Guy
Wed Jun 07 09:15:59 CDT 2006

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

> "Jean-Guy Marcil" <NoSpam@LeaveMeAlone> wrote in message
> news:%236zg%23ajiGHA.4140@TK2MSFTNGP03.phx.gbl...
>> 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?
>
> 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
jmarcilREMOVE@CAPSsympatico.caTHISTOO
Word MVP site: http://www.word.mvps.org

Ed
Thu Jun 08 05:56:42 CDT 2006

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
Thu Jun 08 12:03:13 CDT 2006

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
jmarcilREMOVE@CAPSsympatico.caTHISTOO
Word MVP site: http://www.word.mvps.org

EscarHolmez
Thu Jun 08 12:59:13 CDT 2006

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/microsoft.public.word.application.errors/browse_frm/thread/9575698815035a24/d787ac2159b92079?lnk=st&q=delete+commandbar+file+size+word&rnum=1&hl=en#d787ac2159b92079

http://groups.google.com.au/group/microsoft.public.word.vba.customization/browse_thread/thread/6a33212adb92466c/399375667d146634?lnk=st&q=commandbar+delete+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
Thu Jun 08 15:07:50 CDT 2006

EscarHolmez@gmail.com was telling us:
EscarHolmez@gmail.com 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/microsoft.public.word.application.errors/browse_frm/thread/9575698815035a24/d787ac2159b92079?lnk=st&q=delete+commandbar+file+size+word&rnum=1&hl=en#d787ac2159b92079
>
> http://groups.google.com.au/group/microsoft.public.word.vba.customization/browse_thread/thread/6a33212adb92466c/399375667d146634?lnk=st&q=commandbar+delete+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
jmarcilREMOVE@CAPSsympatico.caTHISTOO
Word MVP site: http://www.word.mvps.org

EscarHolmez
Sun Jun 11 19:11:00 CDT 2006

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.