Mail merge .. . If Then Else

[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