Relative Paths in Word Fields (All)

#1 User is offline   macropod

  • Silver Lounger (over 1600 posts)
  • Group: Moderator
  • Posts: 2386
  • Joined: 2002-05-11
  • Location:Canberra, Australian Capital Territory, Australia

Posted 2008-08-31 21:32

A couple of years ago, a few of us spent a considerable amount of effort tring to coerce Word into applying some sort of relative path addressing for fields pointing to other files. These include Word's INCLUDEPICTURE, INCLUDETEXT, LINK, RD & HYPERLINK fields.

Well, here's a solution (based on an idea originally posted in the microsoft.public.word.mailmerge.fields NG by Peter Jamieson, another MS Word MVP) using INCLUDEPICTURE fields as an example:

First off, Insert a FILENAME field, with the path switch (see under Insert|Field), anywhere in your document.
Next, press Alt-F9 to reveal your document's field codes. A FILENAME field will look like:
{FILENAME \p}
and an INCLUDEPICTURE fields will look something like:
{INCLUDEPICTURE "C:\\My Documents\\My Pictures\\Image.png "}
or:
{INCLUDEPICTURE "C:/My Documents/My Pictures/Image.png "}
Some fields might have other switches after the file's name, which you might want to keep, but they aren't relevant to the rest of the discussion below. You can find out what the switches are for from Word's help file, or via Insert|Field.

To make an INCLUDEPICTURE field look in the current folder, cut & paste the FILENAME field into it, replacing the document path and inserting '\\..\\' or '/ /' between that and the hyperlink file's name, thus:
{INCLUDEPICTURE "{FILENAME \p}/../Image.png"}
or
{INCLUDEPICTURE "{FILENAME \p}\\..\\Image.png"}

How this works: The FILENAME p field extracts the current file's name and path. The following '\\..\\' or '/../' tells Word to ignore the filename and get just the path. Then all you need to do is to add the source file's name & extension.

The same approach can be extended to implement a form of relative addressing. For example:
{INCLUDEPICTURE "{FILENAME \p}\\..\\My PicturesImage.png"}
looks in the child folder named 'My Pictures' and:
{INCLUDEPICTURE "{FILENAME \p}\\..\\..\\Image.png"}
looks in the parent folder, while:
{INCLUDEPICTURE "{FILENAME \p}\\..\\..\\My Pictures\\Image.png"}
looks in the parent folder, then its child folder named 'My Pictures' (a sibling folder, so to speak).

Note: Whilst you can go down the file tree by adding however many sets of '\\..\\' you need, you've got to give explicit folder names for navigating back up it.

If you've got a lot of links to convert, you can use Find/Replace to do the grunt work. For example suppose you've got a document in the folder 'C:\Users\Joe Blow\Documents' and a series of INCLUDEPICTURE fields coded like '{INCLUDEPICTURE "C:\\Users\\Joe Blow\\Documents\\Images\\MyPic.jpg"}'. In this case, the images are in a child folder hanging off the 'Documents' folder. The process you'd use is:
1. Press Alt-F9 to reveal the field codes.
2. Copy 'INCLUDEPICTURE "C:\\Users\\Joe Blow\\Documents' and paste it into the 'Find' box. Do a 'Find' to lock it in.
3. Create a FILENAME field, with the path switch (see above) and insert 'INCLUDEPICTURE "' into the document immediately before it.
4. Cut the 'INCLUDEPICTURE "' and FILENAME field from the document. This puts them in the Windows Clipboard.
5. Insert '^c' in the 'Replace box.
6. Click on 'Replace All'.
7. Copy '\\Images' and paste it into the 'Find' box.
8. Type '\\ ^&' into the 'Replace' box.
9. Click on 'Replace All'.
10. Press Ctrl-A then F9 to update the fields.
11. Press Alt-F9 to hide the field codes.

Note: The reason for mucking around with the 'INCLUDEPICTURE "' copying & cutting is to avoid updating other kinds of links.

The above solution works with INCLUDEPICTURE, INCLUDETEXT, RD & HYPERLINK fields, but not with LINK fields. It doesn't work with LINK fields because they have the nasty habit of converting any embedded fields to plain text immediately they're updated.

Also attached is a macro I've created for automatically updating the field paths for INCLUDEPICTURE, INCLUDETEXT, RD, HYPERLINK & LINK fields. To use it, simply extract the file from the zip archive, open up the Word VBE (Alt-F11) and import the file into the document you want to use it with, then save the document.

Attached file(s)


This post has been edited by macropod: 2009-10-15 20:31
Reason for edit: Added code to the macro to handle documents protected for forms and for folder offsets


#2 User is offline   Slinky

  • Slinky
  • Group: Member
  • Posts: 84365
  • Joined: 2002-03-22

Posted 2007-10-12 03:05

Hi macropod,

That is a very interesting approach. It works fine for me with the INCLUDETEXT and HYPERLINK fields.
For INCLUDEPICTURE fields, however, it only works until the document is saved. At that point, the FILENAME field disappears, to be replaced by the relative path of the picture. I'm using Word 2002 SP3.

#3 User is offline   macropod

  • Silver Lounger (over 1600 posts)
  • Group: Moderator
  • Posts: 2386
  • Joined: 2002-05-11
  • Location:Canberra, Australian Capital Territory, Australia

Posted 2007-10-12 11:49

Hi Hans,

Thanks for the feedback. This is the first instance I've heard of INCLUDEPICTURE fields doing that. They behave as described in Word 2000 and Word 2007.

Evidently there's something odd about Word 2002 SP3.

#4 User is offline   Slinky

  • Slinky
  • Group: Member
  • Posts: 84365
  • Joined: 2002-03-22

Posted 2007-10-12 12:44

The macro you added does work in Word 2002 SP3 for INCLUDEPICTURE fields (but then, Word 2002 tends to change the path in an INCLUDEPICTURE field to relative at the drop of a hat...)

#5 User is offline   silverback

  • 5-Star Lounger (over 600 posts)
  • Group: Member
  • Posts: 706
  • Joined: 2001-01-16
  • Location:Warrington, Cheshire, England

Posted 2008-08-31 21:00

Hello, Macropod.
I'm trying to implement your VB solution for relative links. I've imported the file but it's not working. I've proved that the AutoOpen routine is not being entered (by putting a MsgBox at the start; this never gets executed)
Have you any ideas about why this should be? What have I done/not done?
Thanks
Silverback

#6 User is offline   macropod

  • Silver Lounger (over 1600 posts)
  • Group: Moderator
  • Posts: 2386
  • Joined: 2002-05-11
  • Location:Canberra, Australian Capital Territory, Australia

Posted 2008-08-31 21:06

Hi Silverback,

Are you sure you've put the macro in a module attached to the document you're trying to update, and not its template or the Normal.dot template?

Also, have you checked that your macro security level isn't set too high?

#7 User is offline   Slinky

  • Slinky
  • Group: Member
  • Posts: 84365
  • Joined: 2002-03-22

Posted 2008-08-31 21:09

It's not your fault. AutoOpen doesn't run when it's declared as a private procedure. To correct this, change the line

Private Sub AutoOpen()

to

Public Sub AutoOpen()

#8 User is offline   macropod

  • Silver Lounger (over 1600 posts)
  • Group: Moderator
  • Posts: 2386
  • Joined: 2002-05-11
  • Location:Canberra, Australian Capital Territory, Australia

Posted 2008-08-31 21:26

Thanks Hans,

I wasn't aware of that.

#9 User is offline   Slinky

  • Slinky
  • Group: Member
  • Posts: 84365
  • Joined: 2002-03-22

Posted 2008-08-31 21:34

To be frank, I wasn't aware of it either (I had tested your macros by running them manually), but it was the only thing that struck me as a possible explanation for AutoOpen not running, and it turned out to be so.

#10 User is offline   silverback

  • 5-Star Lounger (over 600 posts)
  • Group: Member
  • Posts: 706
  • Joined: 2001-01-16
  • Location:Warrington, Cheshire, England

Posted 2008-09-01 01:56

Many thanks to Paul and Hans thankyou
I changed the declaration of AutoOpen as Hans suggested and lowered the macro security level to medium (so Word prompts me) as Paul suggested and it's all working!

This is going to save me literally hours of work and make the output more usable for the end users (because they will be able to update links without having to globally edit the links - obviously very error prone - which is all I was (cap)able to do for them this year.)

Thanks again
Silverback

#11 User is offline   jen

  • Registered Lounger
  • Group: Member
  • Posts: 20
  • Joined: 2008-03-23

Posted 2008-10-03 18:33

Hi Macropod

Will your addin accept 2007 file extensions now - the version I currently have does not?

#12 User is offline   macropod

  • Silver Lounger (over 1600 posts)
  • Group: Moderator
  • Posts: 2386
  • Joined: 2002-05-11
  • Location:Canberra, Australian Capital Territory, Australia

Posted 2008-10-04 22:30

Hi Jen,

Are you referring to the macro? Or to the field coding? The macro was last updated in September this year, but I'm not aware of anything in the code that prevents it from working with Word 2007 files. Do note, though, that macros don't work in files saved in the docx format - you must use either the old doc format or the new docm format if your file has macros.

#13 User is offline   jen

  • Registered Lounger
  • Group: Member
  • Posts: 20
  • Joined: 2008-03-23

Posted 2008-10-04 22:56

Hi,
I was just reading the text in a previous version that said this only works with doc or dot files - so I was assuming it didn't like 4 characters .dotx etc in 2007. Thought I'd ask you it is much quicker.

Thanks

#14 User is offline   macropod

  • Silver Lounger (over 1600 posts)
  • Group: Moderator
  • Posts: 2386
  • Joined: 2002-05-11
  • Location:Canberra, Australian Capital Territory, Australia

Posted 2008-10-05 10:09

Hi jen,

I'm not aware of anything indicating

this only works with doc or dot files


#15 User is offline   jen

  • Registered Lounger
  • Group: Member
  • Posts: 20
  • Joined: 2008-03-23

Posted 2008-10-05 10:44

Hi Macropod

10-261488 FieldLinkUpdater
"Source filenames are expected to have a 3-letter extension (eg filename.ext). If they do not, the macro will not work correctly."

Obviously it doesn't matter then. Thank you.

#16 User is offline   macropod

  • Silver Lounger (over 1600 posts)
  • Group: Moderator
  • Posts: 2386
  • Joined: 2002-05-11
  • Location:Canberra, Australian Capital Territory, Australia

Posted 2008-10-05 20:33

Hi jen,

10-261488 FieldLinkUpdater
"Source filenames are expected to have a 3-letter extension (eg filename.ext). If they do not, the macro will not work correctly."
Ah, that quote is from a different thread - see post 261488. Whilst the subject is related, it isn't quite the same. The Field Link Updater in post 261488 would indeed need some changes to work with files having 4-character extensions. Neither the field coding nor the macro attached to the originating post in this thread (post 670027) would need such a change.

#17 User is offline   burtinh

  • Registered Lounger
  • Group: Member
  • Posts: 3
  • Joined: 2008-10-22
  • Location:Sunnyvale, California, USA

Posted 2008-10-22 02:21

Hi, Paul.

First, thanks for posting the macro. I am trying to use it on a Word 2007 (.docm) file, and it's not working quite as expected--I just want to make sure I have not missed something.
The Word 2007-source file and the referenced Excel file reside in the same subdirectory (as will all referenced files).

Here's an example of what I see in the original (.docx without macro) and after (.docm with macro):

(.docx)

{LINK Excel.Sheet.8 "E:pdwDataWorkAVCINGPDARSAVCING_PDARS_Formats.xlsx!NamingConvention!R1C1:R11C4" "" a p }


(.docm)

{LINK Excel.Sheet.8 "C:Documents and SettingsbehDesktoptests:R63C6" "" a p }

The change omitting/changing the Excel object's name/reference pointer has me stumped.

So, the macro is working--just not quite as expected, leaving the objects still inaccessible afterward. Any help you can be will be most appreciated.

Best regards,

Buddy

#18 User is offline   macropod

  • Silver Lounger (over 1600 posts)
  • Group: Moderator
  • Posts: 2386
  • Joined: 2002-05-11
  • Location:Canberra, Australian Capital Territory, Australia

Posted 2008-10-22 09:48

Hi Buddy,

Welcome to the Lounge.

I'me not sure what you mean by "leaving the objects still inaccessible afterward". As written, the macro changes the link path to the folder the Word document is in. Naturally, therefore, your Excel workbook would need to be in the same folder for the link to work - if it isn't you'd need to change the code to modify the new path to suit (eg by adding a child folder's name).

#19 User is offline   burtinh

  • Registered Lounger
  • Group: Member
  • Posts: 3
  • Joined: 2008-10-22
  • Location:Sunnyvale, California, USA

Posted 2008-10-23 01:36

Sorry, Paul.

I didn't realize that it changes the path, the file name, and the pointers, as it did for every instance in the .docm I used it to modify (re: the example I posted). I thought it was supposed to change only the path, leaving the file name and pointers intact. Because the .docx linked reference was in the format...

{LINK Excel.Sheet.8 "E:pdwDataWorkAVCINGPDARSAVCING_PDARS_Formats.xlsx!NamingConvention!R1C1:R11C4" "" a p }

...in the .docm (macro-modified version) I was expecting...

{LINK Excel.Sheet.8 "C:Documents and SettingsbehAVCING_PDARS_Formats.xlsx!NamingConvention!R1C1:R11C4" "" a p }

...(which would make sense because, as I stated in my original post, the Word file and Excel file DO reside in the same folder)...

...BUT, in the .docm (macro-modified version) what I got was...

{LINK Excel.Sheet.8 "C:Documents and SettingsbehDesktoptests:R63C6" "" a p }

...which has no file name at all, and the only pointer that is left is not even remotely related to the original...

Best-

Buddy

#20 User is offline   macropod

  • Silver Lounger (over 1600 posts)
  • Group: Moderator
  • Posts: 2386
  • Joined: 2002-05-11
  • Location:Canberra, Australian Capital Territory, Australia

Posted 2008-10-23 12:26

Hi Buddy,

What you're reporting is really strange. There is nothing in the code to change the filename or pointers - only the path should be changed (to reflect the current path). I can't see any way the code could do what you're reporting.

Can you post a 'sanitized' copy of your file for me to look at?


1 reading this thread
0 members, 1 guests, 0 anonymous