Includetext Field & Relative Paths (Word 2000/SR-3)

Topic

New Reply

I’ve just discovered something about the INCLUDETEXT field & why relative paths sometimes work & sometimes give an error message such as “!Syntax Error” or “Error! Cannot open file.” A relative path will work (at least in Word 2000) only if the File/Open… dialog box is set to the same folder.

I posted a method of using continuous page numbering between separate files in post 27832. In that post, I mentioned that using a complete path & double backslashes, such as:

{INCLUDETEXT “C:My DocumentsFolderSubFolderChapter 1.doc” bmk1 !}

would always give a correct result. I also mentioned that if the source & target document were in the same folder, that you could use:

{INCLUDETEXT “Chapter 1.doc” bmk1 !}

Several people have said that using a relative path like that would give an error message. Now I know why. If you change the File/Open… to My DocumentsFolderSubfolder (in the example above), you will not get that error message.

I wonder if someone who has access to other versions of Word could verify my observations.

Reply | Quote

Replies

Tested under Word 2002 on Windows XP Pro and gives similar behaviour

Created X.doc in StuartTemp
{ Includetext } another file in StuartTemp
Close word
Edit included file
Double clicked X.doc
Checked that File > Open not pointing to StuartTemp
Right click the included text and update works fine
Open another file in another folder from the File Open menu
Right click the included text in X.doc and update now gives “Error not a valid filename”

StuartR

Reply | Quote

Thanks, Stuart. This sure seems like poor design, as it means that if you open a file from either Windows Explorer or the Word MRU list, you can get an error message. Makes it difficult to distribute target & source documents that have INCLUDETEXT fields.

Seems to me that one way around this is to have an AutoOpen macro that changes the current folder. Of course, if you have open other documents from a different folder, you can still get this problem. Any ideas of how to get around this?

Reply | Quote

When I opened a file from Windows Explorer, the INCLUDETEXT field updated correctly. It only gave a problem if I opened a file from another folder and then tried to update the INCLUDETEXT field.

A better alternative to an AutoOpen macro would be an UpdateFields macro that changes the current folder (see post 249730)

StuartR

Reply | Quote

Hi Stuart:
When I move both files, target & source, to a new folder (which is not the folder specified under Tools/Options/File Locations/Documents) & then open them from Windows Explorer, I get an error as soon as I try to update the fields. Is that the behavior you see…or did I misunderstand? You said that the field updated correctly when you opened it from Windows Explorer. I’m not sure, but I think the field doesn’t update when you open it…just displays what it last showed when you closed it. Is this not true?

The UpdateFields macro in post 249730 doesn’t change the current folder. Right now, I’m using an UpdateFields macro that Bryan Carbonnell wrote that updates all fields in all stories.

Reply | Quote

Mine (Office XP on Windows XP) is slightly different to yours

If I have the two files in the same folder then I can move them to a new folder, double click to open, and update fields successfully.
If I then choose File > Open > Cancel and try to update fields again I get the error.

The reference to [post# 249730] was simply meant to point out that an UpdateFields macro could be used to intercept F9, I knew the code to fix this wasn’t there, but I didn’t think it would be hard to add.

StuartR

Reply | Quote

Use of relative paths is NOT transportable unless an app is designed to make use of such paths.

For example, many web sites are designed using relative paths for links.
In my case, I do that so I can maintain the same directory tree structure on my PC, edit the HTML source, and plunk the files back on the Ubix system hosting the URL, with no change in the link code.

If I were to (in)advertently change tghe directory structure on eithr the unix system or my PC, whithout changing the structure on the other, then the links would break.

This is by design and the way it must be.

Reply | Quote

Hi Howard:
Thanks for responding. The problem I see is that if I were to create, say, a manual where File 1 contained Includetext & Includepicture fields referencing Files 2 & 3, all in the same folder. Suppose your folder structure is different than mine. If I use the full filepaths & send them to you, they won’t work. If I use relative paths & you place them all in the same folder, they still won’t work…or so it seems, unless you switch to that folder under File/Open. Do you have a way around this?

Reply | Quote

For example:

1. You have a file Stuff.doc that has a relative reference to a file MoreStuff.doc in the same directory.
2. You move BOTH files to a different directory.
3. You then use Word to Open Stuff.doc.
4. Update the fields in Stuff.doc.
5. The relative reference should still be valid.
6. Whilst in the same Word session, you decide to Open a file, say, Furry.doc in a different directory.
7. Whilst still in the same Word session, you switch back to the Stuff.doc window.
8. Again, update the fields in Stuff.doc.
9. Now, the relative reference will be invalid because opening Furry.doc caused the current directory to change.
10. That’s by design and is correct behavior, if one uses relative paths.

Reply | Quote

I agree that’s what happens. In your step 3, if you open the file from Windows Explorer, & it is not your default Documents folder, update fields produces an error. This may be by design, but I don’t know why it’s a good design. If, in your example, you use relative hyperlinks instead of Includetext fields, the hyperlink will work as long as you maintain the same relative folder structure, regardless of whether Word current folder is changed or not. I don’t see why Includetext fields couldn’t have been designed similarly.

Reply | Quote

I’m no expert with fields, but could you do something with the { Filename p } field and a quote field or two to extract the path to the current file and use that in your IncludeText field?

StuartR

Reply | Quote

Thanks for the idea, Stuart. But I can’t think of a way to get the path of another document with a field in the current document. It would be nice to be able to use a full path in the target document minus the document name like

{ includetext “{ quote { = { FILENAME p } – { FILENAME } + source.doc } }” }

but unfortunately, I can’t think of a way to break up or subtract part of a string in a field. I haven’t seen anything in the MS Knowledge Base or any of the newsgroups either.

Reply | Quote

Hi Phil,

I tried bookmarking just the path part of the string returned via {filename p}, but it get’s clobbered as soon as {filename p} is updated, and I couldn’t include the drive letter without selecting the whole field.

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Thanks for trying. It would be nice to have a seemless way that would work. I even tried:
{ includetext “{ HYPERLINK “Source.doc” }” }
since the hyperlink field alone would always work when I moved both the source & target documents. But, alas, this returned an error also.

Reply | Quote

Hi Phil,

I’ve found one way of doing this, but it’s a bit ugly:
In your source document, create a TOC field such that the whole of the text appears in the TOC. You might do this by including style references via the t switch, and eliminating page numbers with the n switch.
In your target document, create a new TOC and append an RD field to the end of it, naming the source document. RD fields allow relative referencing via the f switch so, if you keep both documents in the same folder, or they are transported within the same folder heirarchy, everything should work OK.

As I said, though, it’s a bit ugly.

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Hi macropod:
This is an interesting solution. Yes, it does tend to work. The only limitation is that the source document (or at least the part that you want to appear in the target document) must be in a certain style. This limits the formatting of the source document. However, it does work with graphics & is useful if you have a bunch of illustrations, each in a separate file. But this is a neat trick that I want to tuck away. Thank you.

Reply | Quote

Hi Phil,

Actually, I found that I could include as many styles from the source document as I wanted. All I had to do was nominate each syle with the t switch in both the source and target documents.

Another limitation that I forgot to mention earlier was that I couldn’t get it to reproduce graphics etc unless they were in-line. It’s not clear from your last reply whether you encountered this also.

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

(Edited by Phil Rabichow on 06-May-03 11:42. )

Hi macropod:
Yes, I found that graphics that weren’t inline couldn’t be brought over. It seems that if you have text that’s in the same style in both the source & target documents that the RD field is bringing over both. However, I’m getting inconsistent results. Do you think you can look at the two files that I’ve attached?

Later:
I seem to come up with these rules, but I’ve been looking at them for so many hours that my mind is mush. Do you agree with the below statements or do you think they are incorrect or incomplete?

To use a combination of TOC & RD fields to simulate an INCLUDETEXT field:
1. You must create a style or styles in the source document.
2. A TOC field must be inserted, using the n switch to suppress page numbers & the t “StyleName” switches for each style to be included. It’s syntax is:
{toc n t “SourceStyle1” t “SourceStyle2”} etc.
3. The styles referenced by the TOC must be copied to the current document. There needn’t be any paragraphs of that style in your target document, but it must exist in the Format/Styles

Reply | Quote

(Edited by macropod on 07-May-03 13:04. See Footnote)

Hi Phil,

Glad you’ve made progress with this. I think I can add that no graphics will be imported via this process.

As for there being only one RD field, I think you might be able to have more provided the styles referenced by the associated TOC are unique to that TOC. I haven’t tried it yet, though.

Cheers

Footnote:

Further testing reveals that in-line graphics are imported but, even if TOC fields in source apply to only only style each, and the corresponding RD fields in the target reference only one style each, each RD field gets duplicate records.

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Hi Stuart,

Unfortuantely, there’s no way short of a macro to extract the path. {Filename p} returns the filename and path. Since you’d be running the macro in the target document, you’d then need to discard the filename, which is easy enough. Then you’d need to convert the path backslashes to double backslashes – because that’s how they have to be input in the field. Finally, extract the source file’s name (from the previous includefield statement?) and add that to the end of the modified path and paste the lot back into the original includefield without upsetting bookmarks & switches.

So, now that you know what’s involved, care to give it a try? Or maybe there’s a better way – I’m not sure anything’s gained by using {Filename p} in the macro.

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Relative path works only:

1. If the current directory happens to be the same as the one used when the relative path was gdefined.
2. The current directory happens to have appropriate files in approppriate directories relative to that current directory.

Reply | Quote

Phil

As a latecomer to this discussion can you try this and see if it works on your machine. It seemed to do the trick on my Word 2000 box. I didn’t test it with a bookmark but using the old dos trick of going up a level and then coming back in appears to work here.

Instead of the too simple field of {INCLUDETEXT “Chapter 1.doc” bmk1 !} that SHOULD work – what if the link looked like {INCLUDETEXT “..Chapter 1.doc” bmk1 !}

Note: I didn’t test this at the root level of the drive and don’t know what you get if this is the case.

Reply | Quote

Hi Andrew,

I’ve just tried this with the files Phil posted .. and it didn’t work. Adding the .. before the filename made no difference to the error message. Nor did having only one dot (eg .Source.doc or .Source.doc) with or without the quotes.

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Hmm

Now that I retest it, I can’t get it to work either. When I tried it before I had several fields with different variants and adding the .. worked, or so I thought, but now the added path information isn’t working at all.

I guess this is the reason I am not a software tester

Reply | Quote

Hi Andrew:
Thanks for the information. I can get it to work when I first create both files & if I set the File/Open… dialog to the same folder that both the source & target are in. After that, they don’t update when you move them. The RD fields will, except sometimes. I put a source & target document in the same folder, used relative paths with the RD field. Then I moved the Source.doc to C: & the target.doc to C:Windows or to C:Data. I used the syntax:

{ RD “..Source1.doc” f }

& it worked. I could actually use { RD “Source1.doc” f } & it worked, too. But when I closed & reopened the target.doc, it put back the 2 dots by itself.

The TOC & RD is an interesting approach, certainly not what RD fields were intended for. It would be nice for the Includetext fields to update relative links, like the RD field. Something for the wish list.

Reply | Quote

Hi Phil,

Remember: [indent]

---

It would be nice for the Includetext fields to update relative links, like the RD field. Something for the wish list.

---

[/indent]
Because I need something to cope with drive/folder changes on a network drive, I’ve coded the attached to update INCLUDETEXT links for target files located in the same folder as their source files.

More work could be done to allow the user to nominate the path, but I don’t need that right now. Code could easily be modified to work with other field types too.

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Nice job!! I only tested it with text, but it worked fine. I did find that it caused Word to crash, if I changed the source filename without changing it in the field, but my system is acting funny lately, with several crashes.

I do have two questions though.
1. I did not see the purpose of the QUOTE field. Changing this to anything else did not affect the behavior of the document.
2. I found that I could change the SET field to anything without affecting the document. i.e. putting in an invalid filename & path didn’t seem to change anything, so I’m not clear what the path is for.

Reply | Quote

Hi Phil,

The QUOTE & SET fields don’t have any particular use – they’re left-overs from testing to make sure that only INCLUDETEXT fields were modified.

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Ah, well that’s different. This is fantastic.

Reply | Quote

Hi Phil,

MKII attached – now includes code (I scrounged it from somewhere then modified it to suit) to select the source folder.

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

I’m jumping on the bandwagon a little late here, and I’m not sure if I shouldn’t have started a new thread… but here’s my question anyway . I have a similar situation with the relative path issue (porting to other drives, machines etc.) but with a fixed directory tree. So, for example, I might want to INCLUDEPICTURE of a graphic that lives in a directory called PICS, which is always below the directory in which the current .doc is resident. Is it possible to use some kind of relative path in this instance? e.g. PICSpicture.jpg

thanks

Alan

Reply | Quote

(Click HERE to view the whole thread in Flat Mode.)
_________________________________________

Hi Alan,

You mean like the attached MKIII version? This lets you specify the field type and select the source folder. True relative paths are beyond its scope, though.

Cheers

Word Field External Link Updater: A Synopsis

When you create a link to an external file (eg another document or a picture) in Word, then move the source file, the link is liable to break. Then you’ll get an error message in the field that does the linking, like:
“Error! Cannot open file.”

The attached document has a macro for updating:
. HYPERLINK
. INCLUDETEXT
. INCLUDEPICTURE
. LINK and
. RD
field links.

You get to choose which type of link to update, and (now) a variety of options for choosing the new source folder(s). Also updated to handle Word’s relative links.

More instructions on how to use the macro are in the document itself.

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Many thanks. I’ll have a play with it.

Alan

BTW, do you prefer to be referred to as macropod, or by your real name?
And don’t tell me that is your real name – nobody’s that absorbed in their field of expertise

Reply | Quote

What’s this real name bit? Keep that up and I’m bound to get hopping mad !!!

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

I actually kicked myself after writing this. I was thinking “macros”, then realised you’re from Canberra. Then the “pod” bit kicked in, and I realised the name originated right here in my own backyard… and yes, we do get them in the backyard! I even looked up the official definition – apparently you’re pretty good eating unless you’re a black wallaroo.
– OY – OY – OY

Alan

Reply | Quote

Hint: Click refresh to animate.

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Hey, you promised you would not show any pictures of me!!

Reply | Quote

I’ve been following this thread with interest because I would like to the INCLUDE TEXT field code in our firm’s letterhead. If I could make it work, I could update the letterhead in one place instead of changing all of the templates that use the letterhead. Unfortunately, we (a law firm) use Docs Open, so the file path would not stay the same. Do you have a suggestion regarding how I can work around this software interface?

Reply | Quote

Hello Towana,

Any document using INCLUDETEXT needs the path to the source document, unless they are both kept in the original folder. I’m not familiar with Docs Open and I don’t know why the path to the source wouldn’t stay the same. Unless the path to the source is particulalrly volatile, the solution I posted should allow users to reconnect the target document with its INCLUDETEXT source (in your case the document with the letterhead) and have it remain linked.

Even so, you might need to re-consider what you’re trying to achieve. If you use INCLUDETEXT to link to your letterhead, any documents prepared using the old letterhead are liable to be updated to the new version next time they are opened, which might not be what you’d want.

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Hi Towana:
Following up on macropod’s suggestion. One way to be able to update letterhead templates quickly (when the logo changes e.g.) is to:
1. Have one source document for the letterhead
2. Use INCLUDETEXT fields for each of the letterhead templates.
3. Have an AutoNew macro in each of the letterhead templates that converts the INCLUDETEXT field to text as soon as you create the document. That way, a new document will have the correct letterhead. But once it’s created, it will remain unchanged, which may be important in the legal setting.
Hope this helps,

Reply | Quote