Skip to main content
Post Undeleted by user1079414
added 4464 characters in body
Source Link
user1079414
user1079414

Assuming you are actually trying to merge the images and not the paths to the images, and assuming that { MERGEFIELD Picture } contains the full path to the image, either with forward backslashes or doubled-up backslashes(NB, eI have made quite a few assumptions here.g If your question is actually about something else altogether then I think it needs clarification).

G:/test/2020090801 includepicture/img003.jpg

Assuming that

  1. you are using the Windows desktop version of Word

  2. you are actually trying to merge the images and not the paths to the images

  3. { MERGEFIELD Picture } contains the full path to the image, either with forward slashes or doubled-up backslashes, e.g.

    G:/test/2020090801 includepicture/img003.jpg
    
    G:\\test\\2020090801 includepicture\\img003.jpg

then you test the MERGEFIELD value but use an INCLUDEPICTURE fieldshould be able to insertdo this, but the imagefield coding is a bit weird.

The field coding that I believe would work in most circumstances is as follows, for example like this:where all the {} are the special field code brace pairs that you can insert using ctrl-F9

{ IF "{ MERGEFIELD Picture }" <> "{ MERGEFIELD PrimaryPicture }" "{ IF { INCLUDEPICTURE "{ IF THINGY { MERGEFIELD Picture } }" } { INCLUDEPICTURE "{ IF THINGY { MERGEFIELD Picture } }" ""}" }

As usualIf you merge to a printer, or merge to email using the {} haveHTML format, that should work.

I you merge that to bea new document using Word 365/2016/2019 and possibly 2013, initially it appears as if the special brace pairsfield codes have all been replaced by the correct pictures. However, if you then save the output, close it, and re-open it, I believe you will actually see that yopu can insertyou are left with ctrl-F9an INCLUDEPICTURE field with an * MERGEFORMATINET option at the end (It's supposed to preserve picture size on Windows desktop Wordreplacement).

If you merge to email using attachments, putthe attachment will be like the saved document. That is, when the recipient opens the attachment, the user may see the pictures (which should be correct) or they may see the field code with the *MERGEFORMATINET. The problem is that the file name in the INCLUDEPICTURE field may be a spacefile name in the file system on either side of the <>computer performing the merge, or even if it is at a public Internet (say http://) address, the recipient may not have access to it. So if they then select those INCLUDEPICTURE fields and although youpress F9, they may be ableend up with a picture border with a red cross and error message in it. Better to remove some oftry to get them to select the quotation marksfields and press ctrl-shift-F9 to "unlink" them, I advise againsti.e. replacing them by their existing result (the image).

InIf you don't use this rather silly-looking construction, what tends to happen is that casethe merge result shows the same picture for every record in the data source. That means that a merge to print can't work, you should end upa merge to HTML email probably won't work, and with a merge to a new document, the actual imagesuser will always have to select and re-execute (notF9) the INCLUDEPICTURE fields) in to get the documentright pictures. HoweverA merge to email attachments works rather like a merge to a new document, so in that case the user would need to update the fields in the attachment they receive. But if any of the images is missingpictures were on the hard disk in the machine performing the merge, you will either getthey won't have them and they'll just see an outline with a red cross and error message or Word may repeat the previous image. 

If you need to cope with thatlook around the Internet, moreyou will probably find a number of places where this approach is needed anddescribed, but unfortunately, people seem to have one of two experiences. Some people experience the above. Others seem to end up with completely unlinked field coding beginscodes and do not have to lookworry about the ctrl-shift-F9 thing. I do not know why this is so. It could be a configuration issue, but I think it is more complicatedlikely that something changed in Word 2013 or 2016.

Incidentally, I believe that if you use this style of coding, even path names with single backslashes, e.g.

    G:\test\2020090801 includepicture\img003.jpg

are processed correctly. However, ISTR that there are some limitations on path length (Incidentallyperhaps a 255 character total path length) and that UNC path names may cause problems even if you double up all the backslashes.

As I mentioned, this is a pretty weird piece of field coding. Normally an IF field looks something like this:

{ IF operand1 operator operand2 "result-if-true" "optional result-if-false" }

e.g

{ IF { x } = 1 "some text" }

but in this case we have

{ IF { INCLUDEPICTURE something } { INCLUDEPICTURE something } }

which doesn't actually fit any of Word's normal IF field patterns at all. Nor does { INCLUDEPICTURE something } generate any kind of "TRUE" result. It just seems to have to be there.

Even the nested code

{ IF THINGY { MERGEFIELD Picture } }

doesn't follow the IF-field syntax pattern. Elsewhere you will probably work even whensee this written as

{ IF TRUE { MERGEFIELD Picture } }

which makes it look as if it fits the pathspattern

{ IF condition "result-if-true" }

but in fact you can use single backslashesany old word (more or less) instead of TRUE. Even FALSE. What you don't seem to be able to do is just use the rather more obvious

{ MERGEFIELD Picture }

on its own. I use THINGY to try to make it clear that there isn't a typical Word logical expression there.

In the situation where you do not need an IF statement to decide whether or not to insert an image, whereasyou can use the basicmuch simpler construction

{ INCLUDEPICTURE "{ IF THINGY { MERGEFIELD Picture } }" }

does notAgain, without the "IF THINGY" part, the merge tends to insert the same image for every record in the data source.

There is another way to insert images without nesting them inside an IF field, which is (broadly speaking) to do it this way:

{ INCLUDEPICTURE "{ IF "{ MERGEFIELD Picture }" <> "{ MERGEFIELD PrimaryPicture }" "{ MERGEFIELD Picture }" "<the path+file name of a 1-pixel picture>" } }

However, you probably need to add in some of the { IF THINGY } stuff to make that work properly too, and I haven't tested it recently.

Assuming you are actually trying to merge the images and not the paths to the images, and assuming that { MERGEFIELD Picture } contains the full path to the image, either with forward backslashes or doubled-up backslashes, e.g.

G:/test/2020090801 includepicture/img003.jpg
G:\\test\\2020090801 includepicture\\img003.jpg

then you test the MERGEFIELD value but use an INCLUDEPICTURE field to insert the image, for example like this:

{ IF "{ MERGEFIELD Picture }" <> "{ MERGEFIELD PrimaryPicture }" "{ INCLUDEPICTURE "{ MERGEFIELD Picture }" }" "" }

As usual, the {} have to be the special brace pairs that yopu can insert with ctrl-F9 on Windows desktop Word, put a space on either side of the <>, and although you may be able to remove some of the quotation marks, I advise against.

In that case, you should end up with the actual images (not the INCLUDEPICTURE fields) in the document. However, if any of the images is missing, you will either get an error message or Word may repeat the previous image. If you need to cope with that, more is needed and the field coding begins to look more complicated.

(Incidentally, this will probably work even when the paths use single backslashes, whereas the basic

{ INCLUDEPICTURE "{ MERGEFIELD Picture }" }

does not.)

(NB, I have made quite a few assumptions here. If your question is actually about something else altogether then I think it needs clarification).

Assuming that

  1. you are using the Windows desktop version of Word

  2. you are actually trying to merge the images and not the paths to the images

  3. { MERGEFIELD Picture } contains the full path to the image, either with forward slashes or doubled-up backslashes, e.g.

    G:/test/2020090801 includepicture/img003.jpg
    
    G:\\test\\2020090801 includepicture\\img003.jpg

then you should be able to do this, but the field coding is a bit weird.

The field coding that I believe would work in most circumstances is as follows, where all the {} are the special field code brace pairs that you can insert using ctrl-F9

{ IF "{ MERGEFIELD Picture }" <> "{ MERGEFIELD PrimaryPicture }" "{ IF { INCLUDEPICTURE "{ IF THINGY { MERGEFIELD Picture } }" } { INCLUDEPICTURE "{ IF THINGY { MERGEFIELD Picture } }" }" }

If you merge to a printer, or merge to email using the HTML format, that should work.

I you merge that to a new document using Word 365/2016/2019 and possibly 2013, initially it appears as if the field codes have all been replaced by the correct pictures. However, if you then save the output, close it, and re-open it, I believe you will actually see that you are left with an INCLUDEPICTURE field with an * MERGEFORMATINET option at the end (It's supposed to preserve picture size on replacement).

If you merge to email using attachments, the attachment will be like the saved document. That is, when the recipient opens the attachment, the user may see the pictures (which should be correct) or they may see the field code with the *MERGEFORMATINET. The problem is that the file name in the INCLUDEPICTURE field may be a file name in the file system on the computer performing the merge, or even if it is at a public Internet (say http://) address, the recipient may not have access to it. So if they then select those INCLUDEPICTURE fields and press F9, they may end up with a picture border with a red cross and error message in it. Better to try to get them to select the fields and press ctrl-shift-F9 to "unlink" them, i.e. replacing them by their existing result (the image).

If you don't use this rather silly-looking construction, what tends to happen is that the merge result shows the same picture for every record in the data source. That means that a merge to print can't work, a merge to HTML email probably won't work, and with a merge to a new document, the user will always have to select and re-execute (F9) the INCLUDEPICTURE fields to get the right pictures. A merge to email attachments works rather like a merge to a new document, so in that case the user would need to update the fields in the attachment they receive. But if the pictures were on the hard disk in the machine performing the merge, they won't have them and they'll just see an outline with a red cross and error message. 

If you look around the Internet, you will probably find a number of places where this approach is described, but unfortunately, people seem to have one of two experiences. Some people experience the above. Others seem to end up with completely unlinked field codes and do not have to worry about the ctrl-shift-F9 thing. I do not know why this is so. It could be a configuration issue, but I think it is more likely that something changed in Word 2013 or 2016.

Incidentally, I believe that if you use this style of coding, even path names with single backslashes, e.g.

    G:\test\2020090801 includepicture\img003.jpg

are processed correctly. However, ISTR that there are some limitations on path length (perhaps a 255 character total path length) and that UNC path names may cause problems even if you double up all the backslashes.

As I mentioned, this is a pretty weird piece of field coding. Normally an IF field looks something like this:

{ IF operand1 operator operand2 "result-if-true" "optional result-if-false" }

e.g

{ IF { x } = 1 "some text" }

but in this case we have

{ IF { INCLUDEPICTURE something } { INCLUDEPICTURE something } }

which doesn't actually fit any of Word's normal IF field patterns at all. Nor does { INCLUDEPICTURE something } generate any kind of "TRUE" result. It just seems to have to be there.

Even the nested code

{ IF THINGY { MERGEFIELD Picture } }

doesn't follow the IF-field syntax pattern. Elsewhere you will see this written as

{ IF TRUE { MERGEFIELD Picture } }

which makes it look as if it fits the pattern

{ IF condition "result-if-true" }

but in fact you can use any old word (more or less) instead of TRUE. Even FALSE. What you don't seem to be able to do is just use the rather more obvious

{ MERGEFIELD Picture }

on its own. I use THINGY to try to make it clear that there isn't a typical Word logical expression there.

In the situation where you do not need an IF statement to decide whether or not to insert an image, you can use the much simpler construction

{ INCLUDEPICTURE "{ IF THINGY { MERGEFIELD Picture } }" }

Again, without the "IF THINGY" part, the merge tends to insert the same image for every record in the data source.

There is another way to insert images without nesting them inside an IF field, which is (broadly speaking) to do it this way:

{ INCLUDEPICTURE "{ IF "{ MERGEFIELD Picture }" <> "{ MERGEFIELD PrimaryPicture }" "{ MERGEFIELD Picture }" "<the path+file name of a 1-pixel picture>" } }

However, you probably need to add in some of the { IF THINGY } stuff to make that work properly too, and I haven't tested it recently.

Post Deleted by user1079414
Source Link
user1079414
user1079414

Assuming you are actually trying to merge the images and not the paths to the images, and assuming that { MERGEFIELD Picture } contains the full path to the image, either with forward backslashes or doubled-up backslashes, e.g.

G:/test/2020090801 includepicture/img003.jpg

or

G:\\test\\2020090801 includepicture\\img003.jpg

then you test the MERGEFIELD value but use an INCLUDEPICTURE field to insert the image, for example like this:

{ IF "{ MERGEFIELD Picture }" <> "{ MERGEFIELD PrimaryPicture }" "{ INCLUDEPICTURE "{ MERGEFIELD Picture }" }" "" }

As usual, the {} have to be the special brace pairs that yopu can insert with ctrl-F9 on Windows desktop Word, put a space on either side of the <>, and although you may be able to remove some of the quotation marks, I advise against.

In that case, you should end up with the actual images (not the INCLUDEPICTURE fields) in the document. However, if any of the images is missing, you will either get an error message or Word may repeat the previous image. If you need to cope with that, more is needed and the field coding begins to look more complicated.

(Incidentally, this will probably work even when the paths use single backslashes, whereas the basic

{ INCLUDEPICTURE "{ MERGEFIELD Picture }" }

does not.)