Evaluating a MERGEFIELD = "RET"

[Michael Holz]

This is a really wierd one. I am guessing that "RET" may have some reserved
meaning and it is interfering with my IF statement, but not sure.

So here is what I'm trying to do. In Office 2003, I'm doing an INCLUDETEXT
thing when a certain MERGEFIELD = "RET" which is something that we pull to a
data .csv file from our database. I've dumbed it down for myself for testing
to take out all but the easy stuff so I could make sure that I isolated the
problem, and I still see this odd issue.

Here's what I've been using for testing when I discovered this issue.

"{IF{ MERGEFIELD AdmitType } = "RET" "test" "what"

No matter what I do this always outputs: what

I have verified that the field in the data file does in fact contain "RET"
by just printing "{MERGEFIELD AdmitType}" in the form letter. The Mergefield
by itself in the form letter prints "RET"

In addition, I've also changed a single letter in the datafile so that
{MERGEFIELD AdmitType} contains "REM" and then changed the one character in
the line of code so that the line of code reads:

"{ MERGEFIELD AdmitType } = "REM" "test" "what"

Then the output in the merge finally reads: test

Any suggestions as to how to get around this? Is there some type of escape
character? Or is anyone else even able to duplicate this?

 

[Peter Jamieson]

Try

{ IF "{ MERGEFIELD AdmitType }" = "RET" "test" "what" }

(If field syntax cannot in the general case be as minimal as is generally
thought - however, in this case, the chances are that the problem is caused
by having a bookmark called RET in your document).

Peter Jamieson

 

[Michael Holz]

Thank you very much. You would think that I would have tried placing quotes
around the MERGEFIELD identifier, but I hadn't.

FYI - Placing the "'s around the {MERGEFIELD AdmitType} did fix the issue,
but just for fun I wanted to see what would happen if I changed the name of
my "RET" bookmark in my bookmarked document. I changed the bookmark name to
RET_Any, deleted the RET bookmark, saved, and then tried running the merge
without the quotes, and I still got a "what" from my code snippet.

So, I'm still not understanding the REASON that the original code isn't
working, but we have changed to the quoted code now, so that it does work.
So, thank you just the same.

It would still interest me to have a full explanation, if you can explain it
to me, but I'm thrilled to have the code working anyway, and I think that the
extra quotes trick should be something I will want to think about in many
subsequent situations with MS.

 

[Peter Jamieson]

It would still interest me to have a full explanation, if you can explain

it
to me,

To be honest, I doubt if I can, without actually looking at precisely what
happened in this case in detail. I have to assume that despite the deletion
of the bookmark, some memory of it remains and affects the field evaluation
code in some way.

If you have a bookmark called abc then you should be able to use

{ IF abc = 1 "T" "F" }

So in the case where { MERGEFIELD xyz } resolves to abc and you use

{ IF { MERGEFIELD xyz } = 1 "T" "F" }

it looks as if Word is doing an extra dereference. However, I'm not sure it
behaves consistently.

{ = } fields should also work with bookmarks without having to wrap them up
as { abc } or { REF abc }. However, because the rules have never been
particularly clear and the documentaiton didn't keep up when MERGEFIELD
fields came in (around Word 2 I think), it's always been difficult to know
what exactly to rely on. All I can say is that in my experience, quoting
MERGEFIELD fields when you are doing text comparisons works more reliably
than not quoting them. OTOH if you know that a { MERGEFIELD } result can
never be the same as any bookmark names in your document, you're probably
OK. There's one place where using { MERGEFIELD } fields causes problems but
it only seems to occur when you also have a SKIPIF field in the Mail Merge
Main Document (again, I would have to guess that the code is old and
something goes back to pre-MERGEFIELD days).

(pre-MERGEFIELD, you could only really have WOrd data sources and the
columns in the data source were treated as bookmarks, e.g. you just used

{ mycolumnname } or { REF mycolumnname } to insert the value. In fact you
can still do it, but only if the data source is read via a built-in
converter (e.g. .doc, .rtf) or comes in via an external converter.

Peter Jamieson

 

[Ed]

Hi Michael (& Peter).

Have a look at this thread to see if it's relevant:

http://groups.google.co.uk/group/mi...d46e4?lnk=st&q=&rnum=1&hl=en#0b8333707ffd46e4

Be warned - it's a tad lengthy

Cheers.

Ed

 

[Michael Holz]

I don't mean to look a gift horse in the mouth, but I thought as informed as
you are you might want all the information.

Just for fun again, I took the Text Variations document that I was using for
my bookmarks. I then made a bookmark with a name of RET_Any, and changed my
..csv datafile to include a datarow with AdmitType populated with RET_Any,
Evaluated the MERGEFIELD against RET_Any with no quotes around the MERGEFIELD
identifier.

The code produced "test" as if it were working like I originally expected.
No need for the quotes. Unlike when we used just RET.

 

[Peter Jamieson]

You really have to think about what you are actually testing when you
explore this area.
a. The relationship between the value of AdmitType and the value of RET_Any
can have (at least) the following logically different patterns:
1. bookmark RET_Any does not exist
2. bookmark RET_Any esists and has value "RET_Any" (This wouldn't be a
special case if you were using a traditional procedural language) and
a. AdmitType = "RET_Any"
b. AdmitType = "XXX"
3. bookmark RET_Any esists and has value "XXX" and
a. AdmitType = "RET_Any"
b. AdmitType = "XXX"
c. AdmitType = "YYY"

You can then have IF statements of the form

w. { IF operand1 = operand2 "T" "F" }
x. { IF operand1 = "operand2" "T" "F" }
y. { IF "operand1" = operand2 "T" "F" }
z. { IF "operand1" = "operand2" "T" "F" }

Where the operand is quoted, its result is always treated as a string.
However, where the operand is not quoted, it will probably be treated as a
bookmark name, if there is a bookmark with that name.

So for example if AdmitType is XXX then any of the following evaluate as "T"
regardless of the existence or value of RET_Any:
{ MERGEFIELD AdmitType } = XXX
{ MERGEFIELD AdmitType } = "XXX"
"{ MERGEFIELD AdmitType }" = XXX
"{ MERGEFIELD AdmitType }" = "XXX"

However, if RET_Any exists and is "XXX" then
{ MERGEFIELD AdmitType } = RET_Any
and
"{ MERGEFIELD AdmitType }" = RET_Any
will also evaluate as "T" but
{ MERGEFIELD AdmitType } = "RET_Any"
and
"{ MERGEFIELD AdmitType }" = "RET_Any"
will evaluate to "F"

If AdmitType is RET_Any, then

{ MERGEFIELD AdmitType } = RET_Any will always evaluate to "T" (because if
there is no bookmark called RET_Any, then both values are treated as the
string "RET_Any", but if there is a bookmark called RET_Any, then both
values are treated as the bookmark, so have the same value anyway. But if
for example the value of RET_Any is "XXX", then

{ MERGEFIELD AdmitType } = XXX
and
{ MERGEFIELD AdmitType } = "XXX" will evaluate to "T" (XXX and "XXX" are
treated as strings, but { MERGEFIELD AdmitType } is unquoted, evaluates to
the name of a bookmark, whose /value/ is compared with "XXX"

"{ MERGEFIELD AdmitType }" = XXX
and
"{ MERGEFIELD AdmitType }" = "XXX" evaluate to "F", because XXX and "XXX"
are treated as the string "XXX" and "{ MERGEFIELD AdmitType }" is treated as
the string "RET_Any"

In the "special" situation where RET_Any is set to "RET_Any", then

{ MERGEFIELD AdmitType } = RET_Any
{ MERGEFIELD AdmitType } = "RET_Any"
"{ MERGEFIELD AdmitType }" = RET_Any
"{ MERGEFIELD AdmitType }" = "RET_Any"

will all evaluate to true.

Not sure if even that is the complete story, but there you go!


Peter Jamieson

 

[Peter Jamieson]

Be warned - it's a tad lengthy

But it ended up succinct

Peter Jamieson

 

[Ed]

Hi Peter,

But it ended up succinct

It did!
................................................................................... Eventually.

Regards.

Ed

 

[Michael Holz]

I was too lazy to read the whole post, but with your information I was able
to figure out what to do and then had a good explanation to get started at
understaning it a little more completly.

I invested my time instead in some hands on learning and found that you did
have to use the Bookmark somewhere in the template document before it would
cause the "inconsistancy" and automatically translate the RET brought in by
the merge field into the bookmark value.

It appears that it is double translating unless we put the quotes around the
reference to the datafile. But I think that was making it even more of a
challenge is that the double translation is not happening all the time. The
reference is treated as just a reference to the datafile if you don't use the
bookmark reference elsewhere in the template.

I don't think the mere existence of the bookmark in a referenced document
(for expamle I have multiple references to a bookmark collection and am
referencing other bookmarks from the file containing the collection) until
you use that specific bookmark in the template document, which makes a LITTLE
more sense after I thought about it.

Thanks again for the help, keep up the good work.



It looks like once a reference is made within the template, that it likes to
take a little shortcut and remember that reference translation.

 

[Ed]

Hi Michael,

I don't think the mere existence of the bookmark in a referenced document
(for expamle I have multiple references to a bookmark collection and am
referencing other bookmarks from the file containing the collection) until
you use that specific bookmark in the template document, which makes a LITTLE
more sense after I thought about it.

I think you're right. I think it's the coincidental presence of the bookmark
in the mail merge main document (mmmd) that's the issue. In my particular
case, it happened that the relevant bookmark was getting into the mmmd when
the INCLUDETEXT file was pulled in by the merge. Prior to the merge the mmmd
would have no bookmarks and the merge would work properly, but after the
merge the bookmarks from the INCLUDETEXT file were in the mmmd and if another
merge was done with the mmmd in that state the problem would happen.

Regards.

Ed

 

[Curt]

can this if be inserted as a nested if as { IF "{ MERGEFIELD contact person
}" = "blank" "cancel print" }
or something similar. My object is if the merge macro finds a blank cell in
the excel sheet. I want it to, cancel the printout at that point.
Have not done this in word.
Any Help I am thankful for
Thanks

 

[Graham Mayor]

You would do better posting your own questions in appropriate forums rather
than appending them to a variety of others scattered across the Word forums.
Please do not multi-post. If you wish to post to more than one newsgroup,
then put all the groups in the same 'send-to' line separated by commas. This
links the messages and minimizes duplication of effort by those who respond
to questions.

You cannot stop a merge by inserting conditional fields into the merge
document. If you want to perform a partial merge then edit your data source
or filter the record set to give the results you require.


--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP


<>>< ><<> ><<> <>>< ><<> <>>< <>><<>

 

[Curt]

I was looking when I posted to this your statement at end answered what I was
trying to do.
Thank You