Home |
Search |
Today's Posts |
#20
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail merge .. . If Then Else
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] |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Word crashes when I try to mail merge using Outlook recipients | Mailmerge | |||
Mail Merge insert merge fields | Mailmerge | |||
Mail Merge | Mailmerge | |||
Heavy Mail Merge Application | Mailmerge | |||
How to get all mail merge fields in a document | Mailmerge |