How to suppress save template prompt (Word COM Add-in)?

[o***@gmail.com]

Hi,

I've written a COM Word add-in that adds a toolbar on connection and
removes the toolbar on disconnection events.

I've seen this topic already discussed in this group, and I learned
that the best practice is to supply an additional global DOT file that
will contain the toolbar, and the COM addin will simply load/unload
that global template.

This works just fine until I want to change something in the toolbar at
runtime. For example, I'd like to disable (gray) some buttons when
there are no open documents and enable it back again when there is one.

The problem is that such operations modify the global DOT file and the
"save mytemplate.dot?" prompt shows up when the user closes the Word
application.

The first solution is to reset the .Saved flag of the template to True
after each such modification. And it works just fine.

However, it conflicts with the case when the user has legally modified
my toolbar (e.g. added a button to it via Tools->Customize). I wish I
could ban such customization but I obviously can't.

A valid response to such situation would be to ask if the user wants to
save the modified template when the application is shut down, but the
above technique (.Saved=True) interferes with this requirement in many
ways.

Does anybody know a workaround? This should be a common problem, so
there should be the best practice of providing custom toolbars in
add-ins, on this level of detail?

Thanks.

[Jonathan West]

Post by o***@gmail.com
Hi,
I've written a COM Word add-in that adds a toolbar on connection and
removes the toolbar on disconnection events.
I've seen this topic already discussed in this group, and I learned
that the best practice is to supply an additional global DOT file that
will contain the toolbar, and the COM addin will simply load/unload
that global template.
This works just fine until I want to change something in the toolbar at
runtime. For example, I'd like to disable (gray) some buttons when
there are no open documents and enable it back again when there is one.
The problem is that such operations modify the global DOT file and the
"save mytemplate.dot?" prompt shows up when the user closes the Word
application.
The first solution is to reset the .Saved flag of the template to True
after each such modification. And it works just fine.
However, it conflicts with the case when the user has legally modified
my toolbar (e.g. added a button to it via Tools->Customize). I wish I
could ban such customization but I obviously can't.

You can't prevent the user from doing such modifications, but you can
prevent them from being saved. Ensure that the Saved property is set to True
whenever the template is unloaded. You can do this in code within your COM
add-in whenever it commands the template to unload. But you can and should
also include an AutoExit macro within the template itself. A macro titled
AutoExit automatically runs immediately prior to a global template being
unloaded. Therefore, setting the Saved property to True there will make it
most unlikely to be saved if the user attempts to unload the template by
hand.

As a further protection, you can set the template file to be read-only, so
that in the unlikely event that the user tries to force a save of the
template, the original will not be affected and the user will be prompted to
save a copy under a new name somewhere.

[o***@gmail.com]

Thanks for your advice!

Still, there are two problems: a technical one and a usability one

The technical problem is that the AutoExit macro (as well as the
OnDisconnection and OnBeginShutdown events, I tried a few others as
well) occur AFTER the "Do you want to save the changes to
mytemplate.dot?" prompt occurs. Is there a workaround?

The other usability problem is that in case if the user can't customize
a toolbar or its customization is (quietly) discarded after re-launch
the application, it may be annoying and is definitely not the intuitive
behavior, you know...

The true solution I'd choose would be to separate user customization
from internal changes of the toolbar and prompt to save the former
while saving/ignoring the latter quietly. Hmm, originally I introduced
my global DOT to avoid modifying user's Normal.dot on one hand and
allow legal user customization of the Normal.dot on the other hand. Now
replace 'Normal.dot' with 'mytemplate.dot' and you see this is the way
to endless loop. Is there any way to resolve this problem?

Thanks!

[Charles Kenyon]

Do not replace normal.dot with a different template. Ever. Period.
--
Charles Kenyon

Word New User FAQ & Web Directory: http://addbalance.com/word

Intermediate User's Guide to Microsoft Word (supplemented version of
Microsoft's Legal Users' Guide) http://addbalance.com/usersguide

See also the MVP FAQ: http://word.mvps.org/FAQs/ which is awesome!

My criminal defense site: http://addbalance.com
--------- --------- --------- --------- --------- ---------
This message is posted to a newsgroup. Please post replies
and questions to the newsgroup so that others can learn
from my ignorance and your wisdom.

Post by o***@gmail.com
Thanks for your advice!
Still, there are two problems: a technical one and a usability one
The technical problem is that the AutoExit macro (as well as the
OnDisconnection and OnBeginShutdown events, I tried a few others as
well) occur AFTER the "Do you want to save the changes to
mytemplate.dot?" prompt occurs. Is there a workaround?
The other usability problem is that in case if the user can't customize
a toolbar or its customization is (quietly) discarded after re-launch
the application, it may be annoying and is definitely not the intuitive
behavior, you know...
The true solution I'd choose would be to separate user customization
from internal changes of the toolbar and prompt to save the former
while saving/ignoring the latter quietly. Hmm, originally I introduced
my global DOT to avoid modifying user's Normal.dot on one hand and
allow legal user customization of the Normal.dot on the other hand. Now
replace 'Normal.dot' with 'mytemplate.dot' and you see this is the way
to endless loop. Is there any way to resolve this problem?
Thanks!

[o***@gmail.com]

Oops, sorry for making you misinterpret what I said. I didn't ever
intend to replace normal.dot, of course.:) Well, let me re-phrase it.

Originally I didn't want to modify user's Normal.dot from my add-in
while retaining the user's right to do so. So, I introduced my own
global template "MyTemplate.dot" for storing my toolbar and kept it
separate from Normal.dot. Now I have the similar problem with
"MyTemplate.dot" as I had with "Normal.dot" - the user still has (?)
the right to customize MyTemplate.dot like he does to Normal.dot, so
the story repeats from the beginning.
But ultimately, I need to have my own user-untouchable "service"
template, for God's sake! :) How can I achieve this?

[Cindy M -WordMVP-]

Post by o***@gmail.com
However, it conflicts with the case when the user has legally modified
my toolbar (e.g. added a button to it via Tools->Customize). I wish I
could ban such customization but I obviously can't.

Actually, you can. Look at the Protection property of the CommandBar
object. Among the various things you can set (and you can set as many as
you like by "adding" them, like MsgBox buttons + icons) is protection
against customization.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question
or reply in the newsgroup and not by e-mail :-)

[o***@gmail.com]

Cool! I wasn't aware of this feature, thanks :)

The only problem is that
1) I don't know which versions of MS Word support it. Generally
speaking, it's a shame that MS Office VBA help doesn't contain version
information as they do in MSDN Platform SDK etc. Or can anybody give me
a link to the handbook?

2) The property unfortunately doesn't apply to menu popups, which I'd
like to use in parallel to the toolbar. You can only disable
customization for the entire menu bar, but it's not what is needed.

[Cindy M -WordMVP-]

Post by o***@gmail.com
1) I don't know which versions of MS Word support it. Generally
speaking, it's a shame that MS Office VBA help doesn't contain

version

Post by o***@gmail.com
information as they do in MSDN Platform SDK etc.

I agree with you 100% on that!

Just so happens I have a virtual machine running at the moment with
Office 97 installed. The property is available in Office 97.

Post by o***@gmail.com
2) The property unfortunately doesn't apply to menu popups, which I'd
like to use in parallel to the toolbar. You can only disable
customization for the entire menu bar, but it's not what is needed.

Hmmm. This isn't something I've ever tested, but on a logical level...

CommandBars(index).controls(index).CommandBar

This is the "path" to a pop-ups menu. Seems to me Protection should
work on this CommandBar, without affecting other things? (Of course, I
could be wrong, but I'm sure you'll let me know if I am.)

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question
or reply in the newsgroup and not by e-mail :-)

[o***@gmail.com]

Unbelievable, it works exactly like you expected! :) Thanks!

The only question left to decide - is it really a good practice to
prohibit the user from customizing my toolbar/menu or let it follow the
standard "intuitive" behavior and write a load of code for correct
handling of such modifications... What do you think?

P.S. BTW can several versions of Office be installed on a single OS,
for testing purposes? I'm afraid no, due to the common files.

[Charles Kenyon]

Outlook can only be in one version on a system (or at least for a single
user on a system). I've had three versions of Word all operating pretty well
on a single system. (I had separate user templates folders for each.)

Post by o***@gmail.com
Unbelievable, it works exactly like you expected! :) Thanks!
The only question left to decide - is it really a good practice to
prohibit the user from customizing my toolbar/menu or let it follow the
standard "intuitive" behavior and write a load of code for correct
handling of such modifications... What do you think?
P.S. BTW can several versions of Office be installed on a single OS,
for testing purposes? I'm afraid no, due to the common files.

[Cindy M -WordMVP-]

Post by o***@gmail.com
Unbelievable, it works exactly like you expected! :) Thanks!

Thank you for confirming that it does :-)

Post by o***@gmail.com
The only question left to decide - is it really a good practice to
prohibit the user from customizing my toolbar/menu or let it follow the
standard "intuitive" behavior and write a load of code for correct
handling of such modifications... What do you think?

I don't see any problem locking out your tools. If I were concerned that
the user might think there's something wrong with Word, I'd put them in
my own toolbar / menu, not "borrow" one of Word's. Then I'd lable these
so that it's clear enough they belong to my "tool". If a user asks, you
can certainly say, "Sorry, the tool is locked against modifications". Any
really determined user can remove the protection as simply as you've
added it, but "the average joe" won't worry about it.

Post by o***@gmail.com
P.S. BTW can several versions of Office be installed on a single OS,
for testing purposes? I'm afraid no, due to the common files.

I used to do this. But since discovering VMWare and the "virtual
machine", I simply set up a VM with the OS and software I'm developing
for :-) It's an investment I've never regretted.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail :-)

[Jonathan West]

Post by o***@gmail.com
P.S. BTW can several versions of Office be installed on a single OS,
for testing purposes? I'm afraid no, due to the common files.

I would recommend not trying to do this. Not because you can't make it work.
Except for limiting yourself to a single version of outlook, you can
persuade different office versions to coexist. But it is not a remotely
realistic setup for other users, and if you are going to be making tools &
add-ins for other users, you want to be able to test under the most
realistic conditions practicable.

If you have a subscription to MSDN, one of the disks includes a copy of
VirtualPC. Dig it out and set up a separate virtual machine for each version
of Office you want to support.

If you don't have MSDN, then you can get VirtualPC or VMWare, both of which
do a similar job.

[Jean-Guy Marcil]

Post by o***@gmail.com
Hi,
I've written a COM Word add-in that adds a toolbar on connection and
removes the toolbar on disconnection events.
I've seen this topic already discussed in this group, and I learned
that the best practice is to supply an additional global DOT file that
will contain the toolbar, and the COM addin will simply load/unload
that global template.
This works just fine until I want to change something in the toolbar
at runtime. For example, I'd like to disable (gray) some buttons when
there are no open documents and enable it back again when there is one.
The problem is that such operations modify the global DOT file and the
"save mytemplate.dot?" prompt shows up when the user closes the Word
application.
The first solution is to reset the .Saved flag of the template to True
after each such modification. And it works just fine.
However, it conflicts with the case when the user has legally modified
my toolbar (e.g. added a button to it via Tools->Customize). I wish I
could ban such customization but I obviously can't.
A valid response to such situation would be to ask if the user wants
to save the modified template when the application is shut down, but
the above technique (.Saved=True) interferes with this requirement in
many ways.
Does anybody know a workaround? This should be a common problem, so
there should be the best practice of providing custom toolbars in
add-ins, on this level of detail?

Here is what I have done when I needed to allow users to save the template
if they made changes, but I was making changes on the fly as well.
So, basically, I know we are not "supposed" to do this, but any way, here
goes...

I set up a global Boolean flag. I set it to True on loading (there were no
changes so the template does not need to be saved).
Then, whenever I programmatically make a change that does not need to be
saved, I check my flag and the .Saved status *before* making my changes. If
they are the same, no problem, when I am done with my changes, I leave my
flag to True and change .Saved to True.
If, before doing my changes, the .Saved status was False but my Flag True
then the use made some changes of its own. I change my flag to False and I
do not reset the .Saved status (I made some changes, but so did the user...
so I do not change the Saved status). So when I next do changes, My flag is
False and so is the saved status. This way, I can tell if the template was
changed by the user because the only way to have my Flag set to False is
when I do changes. Basically, as soon as my Flag becomes False, I stopped
setting the .Saved property back to True after I do changes.

But this will work only when you rest your temporary customization whenever
a document is opened, otherwise, your changes are saved along with the
user's, and that is not good if you are not resetting everything to its
default status when opening documents.

I do not know if this makes any sense... It is a while since I have done
this and I might be forgetting something important... I hope I am not...

[Oleg Krupnov]

Thanks Jean-Guy,

Actually, I've been thinking about exactly the same solution as yours
:).

However, there's a limitation in it. After the user makes any
customization, you lose control on what changes should be saved in your
template and give it away at discretion of the user.

Suppose you have made your own changes to your template (after the
user's customization) and want them to become persistent. You don't
save them immediately and wait for the save prompt. If the user says
"No" to the save prompt on exiting the application, your changes will
be lost.

This one, together with the undesired save of volatile states that you
mentioned, makes me wonder if I should better ban customization at all
as Cindy suggested. Or?..

[Jean-Guy Marcil]

Post by Oleg Krupnov
Thanks Jean-Guy,
Actually, I've been thinking about exactly the same solution as yours
:).
However, there's a limitation in it. After the user makes any
customization, you lose control on what changes should be saved in
your template and give it away at discretion of the user.

This is why I wrote that I only use this with code that automatically reset
all controls/toolbars when opening the document.