Hi Peter,
Whew! That rejoinder is rather more than I bargained for.
However, FWIW your comment about "the field parameter syntax that allows use of { QUOTE 13 } to insert a CR" is wrong. If you try
it, Word will generate the error message "Error! Cannot insert return character." Still, there remains the question of how one
applies the OOXML standards to using { QUOTE 09 } to insert a tab, { QUOTE 11 } to insert a line feed, { QUOTE 12 } to insert a page
break, { QUOTE 14 } to insert a column break, and so on.
--
Cheers
macropod
[MVP - Microsoft Word]
"Peter Jamieson" wrote in message ...
Yes, that's also an option, quite probably in this case. If the user is trying to deduplicate then it requires that the data
source is sorted.
Personally I tend to steer clear of { SKIPIF } on the grounds that
a. it was "deprecated" by Microsoft several versions ago - or at the very least, its use was discouraged
b. it doesn't really do what a user might imagine it does given the name - i.e. it doesn't simply skip records in the data
source; it skips records in the data sorce /and/ causes Word to finish processing the current copy of the mail merge main doc. and
start a new one. Which may be exactly what you want in some cases but will almost certainly screw you up in, e.g., label merges.
However, that's just my view, and there are certainly cases where it's probably the simplest solution. The introduction of the
OOXML standards certainly makes you wonder what Microsoft will do with its "field language" in future versions. If it wants to
conform to the standard, it would probably have to change the way fields work, because AFAICS there are certain areas in which the
standard conflicts with current reality (for example I do not think it describes the field parameter syntax that allows use of {
QUOTE 13 } to insert a CR, and I think it specifies that { DATABASE } always inserts a table, whereas in fact it does not if the
table would only consist of one cell. However, I'd have to check the standard much more thoroughly to be sure. However, since not
conforming to the standard would screw a lot of applications up, and modifying the code would probably be expensive, it seems much
more likely that current field behaviour will be ossified and complaints that Word is non-conformant will be dismissed somehow or
other.
Peter Jamieson
http://tips.pjmsn.me.uk
macropod wrote:
Hi Peter,
Presumably one could also embed a SKIPIF field in the mailmerge main document, coded with logic that is functionally equivalent
to the filter in Excel.