 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWordDirectoryUser Groups Related Topics Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ... |
MS Office Forum / Word / Programming / May 2006How to suppress save template prompt (Word COM Add-in)?
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. > Hi, > [quoted text clipped - 20 lines] > 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.  SignatureRegards Jonathan West - Word MVP www.intelligentdocuments.co.uk Please reply to the newsgroup Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org 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! Do not replace normal.dot with a different template. Ever. Period. SignatureCharles 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. > Thanks for your advice! > [quoted text clipped - 19 lines] > > Thanks! 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? > 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 :-) 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. > 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. 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. > 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 :-) 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. 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.) > Unbelievable, it works exactly like you expected! :) Thanks! > [quoted text clipped - 5 lines] > 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. > Unbelievable, it works exactly like you expected! :) Thanks! > Thank you for confirming that it does :-) > 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. > 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 :-) > 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. SignatureRegards Jonathan West - Word MVP www.intelligentdocuments.co.uk Please reply to the newsgroup Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org oleg.krupnov@gmail.com was telling us: oleg.krupnov@gmail.com nous racontait que : > Hi, > [quoted text clipped - 30 lines] > 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... SignatureSalut! _______________________________________ Jean-Guy Marcil - Word MVP jmarcilREMOVE@CAPSsympatico.caTHISTOO Word MVP site: http://www.word.mvps.org 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?.. Oleg Krupnov was telling us: Oleg Krupnov nous racontait que : > Thanks Jean-Guy, > [quoted text clipped - 4 lines] > 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. SignatureSalut! _______________________________________ Jean-Guy Marcil - Word MVP jmarcilREMOVE@CAPSsympatico.caTHISTOO Word MVP site: http://www.word.mvps.org |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.