Undead Template Links

Topic

New Reply

I created a .dot template in Word 2003 that is giving me some problems. In the footer of the template, I have a field that shows the name of the document. Immediately at the end of that I have a bookmark that is filled in with AutoNew VBA code for the ClearCase version of the file.

As long as people allow macros to run, the footer fills out correctly with document name and version. The only problem I have is if they create a new document on a different drive letter than everyone else uses. If they use different mappings to drives and that particular drive letter does not exist on my computer, the code does not run, and the version number is erroneous.

For example, suppose a user double clicks on the .dot file on his X drive and creates a document. He can open it later and the footer is correct. I have that drive mapped as the Y drive. I open it and the code does not run. The footer is wrong. Opening up the document, the code is not even there. But of course, he will be able to see it with ALT-F11.

When I check Tools > Templates and Addins, I see that the name of the template is stored there, and that it is on the X drive. That helps explain why it does not work on the Y drive: it is looking for the template on a locally non-existent drive.

My question ( at last ) is : why does the template name need to be stored and what can I do to keep this from happening? I can always open up a .doc document with the proper format and bookmark and then paste the AutoNew code in, but who wants to have to do that every time?

Thanks

Reply | Quote

Replies

The only problem I have is if they create a new document on a different drive letter than everyone else uses. If they use different mappings to drives and that particular drive letter does not exist on my computer, the code does not run, and the version number is erroneous.
…
My question ( at last ) is : why does the template name need to be stored and what can I do to keep this from happening?

The path to the template needs to be stored if you want access to the autotext entries and macros after the file is created. If that is not necessary, you can have your AutoNew macro switch the template to Normal to free it of this dependency. Would that work for your application?

The best solution for sharing templates is to connect to the template folder using UNC notation, which is independent of the drive letter. For example: \serversharefoldermytemplate.dot

If that is not possible, your organization should try to enforce uniform drive mappings.

Reply | Quote

I have no need for auto text entries. How would I go about switching the template back to Normal?

Reply | Quote

You can change the template in Tools | Templates and Add-Ins…
Simply enter Normal in the Document Template box and click OK.

Reply | Quote

I believe the problem is an intractable one. Before I ran into the problem with attached templates I had hoped to have an AutoNew macro reside in the created document that would insert the proper version number. Every time the document was updated, the version number would automagically update.

With the way that attached templates work, the code stays in the template, not the new .doc file. As long as the drive mappings are consistent, no problem. But that is not the way the real world operates.

After the .doc file is created from the .dot file, I can go and change the attachedtemplate to Normal. Unfortunately, that makes the code disappear. I can paste code in to the new .doc as AutoOpen, but when there are hundreds of documents, that is a problem. I could write some code to automate that, but what I wanted was code to take care of it as the document is created in the first place.

I can have a .dot template change the attached template to Normal (or anything else), but doing so removes the code I wanted which is still in the old attached template. The only way I could keep the code is to write a hideous kluge or to use a .doc file as the original instead of a .dot file. But that would cause way too many problems for the users (even if I wrote a ton of code to make it behave like a .dot file). They are used to creating a new document by double clicking on a .dot template.

Oh well…

Reply | Quote

As long as the drive mappings are consistent, no problem. But that is not the way the real world operates.

I know this is going to sound crazy, but in our firm login script, we map the key drives on which shared documents are stored so that everyone works off the same drives for those files. Something to consider.

Reply | Quote

I know this is going to sound crazy, but in our firm login script, we map the key drives on which shared documents are stored so that everyone works off the same drives for those files. Something to consider.

Fortunately, most of our users do too, so the problem was not noticed for quite a while. It’s just those few who do things like have different mappings or copy the template to their desktop to create files that cause problems…

Reply | Quote

Fortunately, most of our users do too, so the problem was not noticed for quite a while. It’s just those few who do things like have different mappings or copy the template to their desktop to create files that cause problems…

Per jscher’s suggestions, the best solution would be to enforce some kind of uniform mapping, but if you can’t do that, another kludge available (that might not be hideous to the users) would be to have some code stored in a global add-in template, that could for instance run from a “Re-attach template” button. If you can catalog a finite number of alternate locations (like an X: drive, or the desktop) where users in your organization may be keeping the templates, then you could have code that would extract the template name from the document, and then scan folder locations on the current computer against the list of possible locations you’ve gathered beforehand, until it finds the correct template, and then re-attach it.

Gary

Reply | Quote

Word looks in several places for an attached template including

[*]The folder containing the document
[*]The user templates folder specified in Tools | Options | File Locations
[*]The workgroup templates path specified in Tools | Options | File Locations
[*]The path specified in the attached template

With this information, I would use the workgroup template location to store the details of where the template can be found. If you define the workgroup template location using the URL eg “\servernamefolderfolder” and the attached template resides there then it doesn’t matter how the user has mapped their drives.

Reply | Quote