Re: Evaluating a MERGEFIELD = "RET"
- From: Ed <Ed@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 16 Jun 2007 11:19:00 -0700
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
"Michael Holz" wrote:
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.
"Peter Jamieson" wrote:
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" <Michael Holz@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:13A98DBD-30B8-4C70-8DB1-3F08E4CEBBEA@xxxxxxxxxxxxxxxx
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?
- References:
- Re: Evaluating a MERGEFIELD = "RET"
- From: Peter Jamieson
- Re: Evaluating a MERGEFIELD = "RET"
- From: Michael Holz
- Re: Evaluating a MERGEFIELD = "RET"
- Prev by Date: Re: Where should declarations be? Data Entry & Form Control
- Next by Date: Re: Where should declarations be? Data Entry & Form Control
- Previous by thread: Re: Evaluating a MERGEFIELD = "RET"
- Next by thread: Re: Evaluating a MERGEFIELD = "RET"
- Index(es):
Relevant Pages
|
Loading