[Peter Jamieson]

Hi macropod,

Sadly, all too true. But it's been an interesting exercise in its own
right.

It certainly has!

My interpretation differs: What the tests show is that only version 2
returned the correct result every time with plain vanilla
'XX'- until we got to test 'r'. Versions 2 and 4 of the REF field coded as
'{REF XX}' gave the same results.

I /think/ this is because we have a different understanding of what is being
tested. If your interpretation is that the presence of an XX bookmark means
that "XX" should be interepreted as the result of { XX } then option 4
definitely does not work for case 'XX'. But to me, using "XX" should, and as
far as I can tell, always does, mean that you are testing against the string
"XX" rather than the result of the bookmark XX - in which case, option 4
works every time AFAICS. Is it important? Well, I suppose the reality is
that if you have complete control over every aspect of a merge, you can
avoid problems of this kind as long as you know they exist, and if you don't
have complete control then there are any number of things that could get
screwed up because someone changes something. But I suppose it's worth
trying to guard against the possibility that the user might insert an XX
bookmark in "my" Mail Merge Main document or attach the document to a Word
data source with a column called XX - in which case Word treats the column
names like bookmarks - mostly.

That's another place where you will find a difference between the treatment
of { mybm } and { REF mybm }. If you attach a Word data source with a column
called mybm, Word inserts value of the column mybm when you use those
fields. But the two versions behave diffeerently when you toggle the
preview button: For { mybm }, it always displays the field value. For { REF
mybm } it displays "Error! Reference source not found." in the state where
MERGE fields are shown enclosed in chevrons, but the column value when the
field results are displayed. At least it does, here, right now :-) Using
those column names as if they were bookmarks may be an undocumented feature
(you can use it to insert pictures, for example) whose consequences should
be regarded as unpredictable but of course that does not prevent users from
attaching, quite legitimately, to Word document data sources.

In the end all this stuff probably comes down to the Word code being
developed over time, based on more than one interpretation of how exactly
fields are supposed to behave. For example, if you bookmark a { SEQ } field
as myseq in Word 2003 and use { REF myseq } to reference it, you see the
result of that { SEQ } field. However, way back in Word 2, either { REF
myseq } or { myseq }, or both - I forget which - actually behaved as if it
were another copy of the SEQ field itself and give you the next number in
the sequence. This was very nice for implementing SEQ-based numbering
because you could set a bookmark called (say) l2 to { SEQ level2 \c }.{ SEQ
level1 } and use { l2 } to produce each new number at that level. That
disappeared in Word 6 or maybe later, but perhaps some of the code relating
to REF fields is still in there. My assumption is that even specifying the
field language is non-trivial because of the kind of problem you encounter
when evaluating nested fields - for example, is it obvious how SEQ fields
nested inside IF fields should be evaluated? I don't know.

It was interesting that you seemed to have some different results when you
revisited the problem, because that's pretty much what happened to me
yesterday! In my case I'm pretty sure it was experimental error, but I do
sometimes wonder whehter there isn't some subtle error in Word (perhaps to
do with what you've done during a session, or what bookmarks exist in other
open documents, or some such).

Regards,

Peter Jamieson


Cheers

--
macropod

"macropod" wrote in message
...
Hi Peter,

| Sorry, had to dash earlier and my examples were not quite as I had
tested before posting.
| And certainly with the \*Upper, the "quoteless" example works as you
say.
|
| But I don't actually get the same results as you describe below either.
For example.
|
| 1.
| Yes, that's what I get assuming "nothing" means "1234" :-)

Um, yes - "nothing" means "1234" - Ooops

| 2.
| Here, I don't get 1@2@34 in any circumstances. I wonder why our results
are different?

Nor do I now. Curious. Repeated it a number of times before my last post
...

| If PatientCode is xx or XX, and I input nothing into XX, I get 1@2@3@4@,

Even curiouser, but true.This can be rectified by coding the field along
the lines of:
{IF "{PatientCode \*Upper}" = {XX} T F} or {IF "{PatientCode \*Upper}" =
"{XX}" T F}
but not:
{IF "{PatientCode \*Upper}" = {REF XX} T F} or {IF "{PatientCode \*Upper}"
= "{REF XX}" T F}


| However, I also get the same result if
| PatientCode is xx or XX and I input "XX" (without the quotes) into XX.

Which is as expected.

| If PatientCode is xx or XX, and I input anything except blank or XX into
the
| XX field, I get 1@234@ , i.e. versions 1 and 4 work OK.

No, the result of the test is False; that means only versions 2 & 3 work
in this case.

| If PatientCode is aa, I always get 1234.

Same here, which is what I'd expect.

| 3.
| I get the same

I'm glad.

|
| 4.

OK, so here's a comparison of using the 'XX' bookmark as a plain vanilla
'XX', '{XX}' and '{REF XX}', using the field coded as:
{QUOTE{ASK PatientCode}{ASK XX}
"1"{IF {PatientCode} = XX T F}
"2"{IF "{PatientCode}" = XX T F}
"3"{ IF {PatientCode} = "XX" T F}
"4"{IF "{PatientCode}" = "XX" T F}}
The minor re-coding, to output T/F and reposition the numbers against the
corresponding IF tests, has no effect on the correctness
of the results. I also added a few more tests and omitted your incomplete
'q'.

State 'XX' '{XX}' '{REF XX}'
a. PatientCode=xx,XX=xx: TRUE 1T2T3F4F 1T2T3T4T 1T2T3T4T
b. PatientCode=xx,XX=XX: FALSE 1T2F3T4F 1T2F3T4F 1T2F3T4F
c. PatientCode=XX,XX=xx: FALSE 1T2F3F4T 1T2F3T4F 1T2F3T4F
d. PatientCode=XX,XX=XX: TRUE 1T2T3T4T 1T2T3T4T 1T2T3T4T
e. PatientCode=aa,XX=aa: TRUE 1T2T3F4F 1T2T3T4T 1T2T3T4T
f. PatientCode=aa,XX=AA: FALSE 1F2F3F4F 1F2F3F4F 1F2F3F4F
g. PatientCode=AA,XX=aa: FALSE 1F2F3F4F 1F2F3F4F 1F2F3F4F
h. PatientCode=AA,XX=AA: TRUE 1T2T3F4F 1T2T3T4T 1T2T3T4T
i. PatientCode=aa,XX=xx: FALSE 1F2F3F4F 1F2F3F4F 1F2F3F4F
j. PatientCode=aa,XX=XX: FALSE 1F2F3F4F 1F2F3F4F 1F2F3F4F
k. PatientCode=AA,XX=xx: FALSE 1F2F3F4F 1F2F3F4F 1F2F3F4F
l. PatientCode=AA,XX=XX: FALSE 1F2F3F4F 1F2F3F4F 1F2F3F4F
m. PatientCode=xx,XX=aa: FALSE 1T2F3F4F 1T2F3T4F 1T2F3T4F
n. PatientCode=xx,XX=AA: FALSE 1T2F3F4F 1T2F3T4F 1T2F3T4F
o. PatientCode=XX,XX=aa: FALSE 1T2F3F4T 1T2F3T4F 1T2F3T4F
p. PatientCode=XX,XX=AA: FALSE 1T2F3F4T 1T2F3T4F 1T2F3T4F
q.
r. PatientCode="",XX="": TRUE 1F2F3F4F 1T2T3T4T 1F2F3F4F
s. PatientCode=xx,XX="": FALSE 1F2F3F4F 1F2F3F4F 1F2F3F4F
t. PatientCode="",XX=xx: FALSE 1F2F3F4F 1F2F3F4F 1F2F3F4F

For the plain vanilla 'XX', I get the same results as you did.

| Only the fully quoted version correctly compares PatientCode with "XX"
every
| time.

My interpretation differs: What the tests show is that only version 2
returned the correct result every time with plain vanilla
'XX'- until we got to test 'r'. Versions 2 and 4 of the REF field coded as
'{REF XX}' gave the same results.

My tests also show that only versions 2 and 4 of the REF field coded as
'{XX}' returned the correct result every time, including
test 'r'. I have no idea why omitting 'REF' from the field code should
make a difference to that test, but it does.

My take on this is that it's easier to remember, and therefore safer in
practice, to use quoted REF fields (without the REF) on both
sides of the equation when testing bookmarked strings. As previously
discussed, the testing of bookmarked strings against other
strings needs quotes around any test string that has spaces in it, but not
around the bookmark. However, since the field works with
or without quotes around the bookmark, and having them makes for
consistency with testing bookmarks against each other, I'd have to
endorse putting quotes around everything as the safest way to code an IF
field. I guess I should now go and review/update my
'tutorial' documents.

|
| Which is all very well, but may still not result in a solution for the
| original question...

Sadly, all too true. But it's been an interesting exercise in its own
right.

Cheers

--
macropod
[MVP - Microsoft Word]