Creating code in a .doc (Word 2000-97 PC-MAC)

Topic

New Reply

Hi gang,
I have users taking turns working on a document based on the same template. These users are working on individual computers. They each have a copy of the template installed in the template folder. The template folder path is different for each individual.
I have managed to write code that points the document to the default user template folder and attaches the right template to this document. I am half way there.
I need to create an AutoOpen in every document that will be created based on this template so that every time a user opens the document it will attach the template from that user’s default template folder. I know I will have to put this code in the AutoNew in the template but that is where my “expertise” ends.
Please help.

Reply | Quote

Replies

Are you sure you really need this? Is there other things your macro needs to do beyond just finding a template to attach?

When Word opens a file it has a cascading process for finding the template that is attached to the file. The order appears to be something like this…
1. Use the template in the location specified by the full path for the Attached Template
2. If the template is not there then look in User Templates location for a template with the same name
3. If the template is not there then look in the Workgroup Templates location for a template with the same name
4. If the template is not there then look in the same folder that the Word file is in.

5. Give up looking for the template – the Word file will open but you don’t have access to the attached template.

My version of the order is likely to be wrong but the important thing is that Word will happily find the template if it is located in one of four places.

Reply | Quote

Hi Andrew,
Tks for the tip. The workgroup template seems like the logical approach. However, there are dozens of templates and they are separated in different sub folders in the user and/or workgroup templates location. If I put all the templates in a de fault folder it will make it more difficult for the user to find the right template when creating a new doc. By adding code to every new file created with a specific template I can specify the sub-folder in which this template is located.
Would there be a better way of doing this?
Tks

Reply | Quote

JC

I would be surprised if you need so many templates that folders are really necessary. You can minimise the number of templates you have by following a philosophy of grouping related content inside a common template.

I prefer to create templates so that some of them contain multiple content options. One template can have different contents added automatically at the start depending on what the user decides they want in the file. This way I can create a consistent look across a series of files and only have to maintain styles/logos/code in one template. The different content options are stored as autotext entries in the template and an autonew macro displays the list which is built dynamically based on the autotext entries in the template at the time.

An example is the difference between having 20 different templates for online forms to having one forms template which allows the user to choose which one of the 20 forms the file should contain.

This approach makes it easy to manage updates to the template and automatically caters for new or changed forms at any time. In some templates the autotext entries might contain 100s of pages of content and the parts that are common to all files (eg cover, disclaimer, toc) are only stored once.

If you are wedded to the separate templates model, what about using a macro in the template that looks to a custom property in the file that contains the path to where the template is held. The macro could then run every time the file is opened and work out which path to set the attached template to by using that path contained in the file. This would let you avoid putting code specifically in the document but still enable a macro to run that is specific to that file.

Reply | Quote

JC

I would be surprised if you need so many templates that folders are really necessary. You can minimise the number of templates you have by following a philosophy of grouping related content inside a common template.

I prefer to create templates so that some of them contain multiple content options. One template can have different contents added automatically at the start depending on what the user decides they want in the file. This way I can create a consistent look across a series of files and only have to maintain styles/logos/code in one template. The different content options are stored as autotext entries in the template and an autonew macro displays the list which is built dynamically based on the autotext entries in the template at the time.

An example is the difference between having 20 different templates for online forms to having one forms template which allows the user to choose which one of the 20 forms the file should contain.

This approach makes it easy to manage updates to the template and automatically caters for new or changed forms at any time. In some templates the autotext entries might contain 100s of pages of content and the parts that are common to all files (eg cover, disclaimer, toc) are only stored once.

If you are wedded to the separate templates model, what about using a macro in the template that looks to a custom property in the file that contains the path to where the template is held. The macro could then run every time the file is opened and work out which path to set the attached template to by using that path contained in the file. This would let you avoid putting code specifically in the document but still enable a macro to run that is specific to that file.

Reply | Quote

I fully agree with Andrew concerning the use of multi-purpose templates.
When I took over from my predecessor, there were 300+ templates, scattered all over the place (company server, department server, individual PC’s). Now there are about 70 multi-purpose templates left, all sitting in the WorkgroupTemplates folder.
About 45 are general templates in the main folder, visible to all users. The others are sitting in 4 subfolders named Dep 1, …, Dep 4. Those subfolders are only accessible by authorised users (Novell network folders authorisation model) and so they see a tab with the name of the appropriate department(s), listing the dedicated templates for that department.
Our users are very pleased with this, as it’s very much easier for them to find the template they need and they get “guidance” in the templates themselves as to which choices to make.

Reply | Quote

I fully agree with Andrew concerning the use of multi-purpose templates.
When I took over from my predecessor, there were 300+ templates, scattered all over the place (company server, department server, individual PC’s). Now there are about 70 multi-purpose templates left, all sitting in the WorkgroupTemplates folder.
About 45 are general templates in the main folder, visible to all users. The others are sitting in 4 subfolders named Dep 1, …, Dep 4. Those subfolders are only accessible by authorised users (Novell network folders authorisation model) and so they see a tab with the name of the appropriate department(s), listing the dedicated templates for that department.
Our users are very pleased with this, as it’s very much easier for them to find the template they need and they get “guidance” in the templates themselves as to which choices to make.

Reply | Quote

Ms. JC,

Just stumbled on this thread, and don’t know if it’s now outdated and you have found a solution, anyway:

Notwithstanding Andrew and Jan’s valid suggestions about reducing the number of templates you (and your users) have to deal with, it seems like there is still a missing link in the situation you are describing – are you saying you need this code to run, every time a document based on a specific template is opened, to locate the appropriate template on that individual user’s profile, and reattach that template?

If so, then housing the needed code in the template’s Document_Open or AutoOpen procedure won’t do the trick, because that code won’t even run when the document is opened, if the document is not currently attached to the relevant template that contains the code.

Neither is putting the code into a procedure in the document itself a good approach – as a general rule, you don’t want to be propagating code-bearing documents out into the world – code should stay in the template.

If you do have to run some code to manage the locations of lots of different templates and attach documents to correct templates on Open, then the best place to house that code would be in a global add-in template. You would need to set up an application-level DocumentOpen event procedure. Code in that procedure could determine the name of the template for every document that opens, and then further code could attach the correct template, for those documents that need it.
If the above is relevant to what you’re trying to do, and you need more detail, write back and I’ll track down some working code.

Gary

Reply | Quote

Granted that its probably better not to have code run by the document, but what about putting the code in the Document_Open procedure of the documents ThisDocument module?

Reply | Quote

Assuming for the moment that we’re going to house the code in the document itself – in its ThisDocument module – the next question would be: how do you get the code in there to begin with?

If you put code in a template’s ThisDocument module, that code isn’t going to propagate out to the ThisDocument module of the documents that get created based on the template. So, you’d either have to:

(1) abandon creating documents based on templates. Instead, put all of the needed code into a ‘document which serves as a template’, and always create new documents by opening this ur-document and doing a FileSaveAs. That does create some circular logic though, because if the documents are not going to be based on a template, then you don’t need to be running code to find the document’s template, anyway! The main problem with this approach is that you’re working against the way Word is designed, and giving up the advantages of housing things like code, custom toolbars and autotexts in the template, rather than the document. (On the other hand, that’s how it works in Excel….)

(2) stay with the template/document structure, and have code in the template’s Document_New procedure, which writes the needed code into the Document_Open procedure of each new document, at the time that it’s created – maybe that’s what the original poster is looking to do. Haven’t ever done that myself, but I’m sure it’s possible to do – I’d be nervous that this approach might set off alerts from antivirus software, but if you can get past that, it might be OK.

I still think it’s more straightforward to have any needed code like this, live in a global template, rather than either of (1) or (2) above.

Gary

Reply | Quote

Assuming for the moment that we’re going to house the code in the document itself – in its ThisDocument module – the next question would be: how do you get the code in there to begin with?

If you put code in a template’s ThisDocument module, that code isn’t going to propagate out to the ThisDocument module of the documents that get created based on the template. So, you’d either have to:

(1) abandon creating documents based on templates. Instead, put all of the needed code into a ‘document which serves as a template’, and always create new documents by opening this ur-document and doing a FileSaveAs. That does create some circular logic though, because if the documents are not going to be based on a template, then you don’t need to be running code to find the document’s template, anyway! The main problem with this approach is that you’re working against the way Word is designed, and giving up the advantages of housing things like code, custom toolbars and autotexts in the template, rather than the document. (On the other hand, that’s how it works in Excel….)

(2) stay with the template/document structure, and have code in the template’s Document_New procedure, which writes the needed code into the Document_Open procedure of each new document, at the time that it’s created – maybe that’s what the original poster is looking to do. Haven’t ever done that myself, but I’m sure it’s possible to do – I’d be nervous that this approach might set off alerts from antivirus software, but if you can get past that, it might be OK.

I still think it’s more straightforward to have any needed code like this, live in a global template, rather than either of (1) or (2) above.

Gary

Reply | Quote

Granted that its probably better not to have code run by the document, but what about putting the code in the Document_Open procedure of the documents ThisDocument module?

Reply | Quote

Ms. JC,

Just stumbled on this thread, and don’t know if it’s now outdated and you have found a solution, anyway:

Notwithstanding Andrew and Jan’s valid suggestions about reducing the number of templates you (and your users) have to deal with, it seems like there is still a missing link in the situation you are describing – are you saying you need this code to run, every time a document based on a specific template is opened, to locate the appropriate template on that individual user’s profile, and reattach that template?

If so, then housing the needed code in the template’s Document_Open or AutoOpen procedure won’t do the trick, because that code won’t even run when the document is opened, if the document is not currently attached to the relevant template that contains the code.

Neither is putting the code into a procedure in the document itself a good approach – as a general rule, you don’t want to be propagating code-bearing documents out into the world – code should stay in the template.

If you do have to run some code to manage the locations of lots of different templates and attach documents to correct templates on Open, then the best place to house that code would be in a global add-in template. You would need to set up an application-level DocumentOpen event procedure. Code in that procedure could determine the name of the template for every document that opens, and then further code could attach the correct template, for those documents that need it.
If the above is relevant to what you’re trying to do, and you need more detail, write back and I’ll track down some working code.

Gary

Reply | Quote

Hi Andrew,
Tks for the tip. The workgroup template seems like the logical approach. However, there are dozens of templates and they are separated in different sub folders in the user and/or workgroup templates location. If I put all the templates in a de fault folder it will make it more difficult for the user to find the right template when creating a new doc. By adding code to every new file created with a specific template I can specify the sub-folder in which this template is located.
Would there be a better way of doing this?
Tks

Reply | Quote

Are you sure you really need this? Is there other things your macro needs to do beyond just finding a template to attach?

When Word opens a file it has a cascading process for finding the template that is attached to the file. The order appears to be something like this…
1. Use the template in the location specified by the full path for the Attached Template
2. If the template is not there then look in User Templates location for a template with the same name
3. If the template is not there then look in the Workgroup Templates location for a template with the same name
4. If the template is not there then look in the same folder that the Word file is in.

5. Give up looking for the template – the Word file will open but you don’t have access to the attached template.

My version of the order is likely to be wrong but the important thing is that Word will happily find the template if it is located in one of four places.

Reply | Quote