 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWordDirectoryUser Groups Related Topics Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ... |
MS Office Forum / Word / Programming / June 2007Evaluating a MERGEFIELD = "RET"
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? 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 > This is a really wierd one. I am guessing that "RET" may have some > reserved [quoted text clipped - 33 lines] > escape > character? Or is anyone else even able to duplicate this? Thank you very much. You would think that I would have tried placing quotes around the MERGEFIELD identifier, but I hadn't. FYI - Placing the "'s around the {MERGEFIELD AdmitType} did fix the issue, but just for fun I wanted to see what would happen if I changed the name of my "RET" bookmark in my bookmarked document. I changed the bookmark name to RET_Any, deleted the RET bookmark, saved, and then tried running the merge without the quotes, and I still got a "what" from my code snippet. So, I'm still not understanding the REASON that the original code isn't working, but we have changed to the quoted code now, so that it does work. So, thank you just the same. It would still interest me to have a full explanation, if you can explain it to me, but I'm thrilled to have the code working anyway, and I think that the extra quotes trick should be something I will want to think about in many subsequent situations with MS. > Try > [quoted text clipped - 42 lines] > > escape > > character? Or is anyone else even able to duplicate this? > It would still interest me to have a full explanation, if you can explain > it > to me, To be honest, I doubt if I can, without actually looking at precisely what happened in this case in detail. I have to assume that despite the deletion of the bookmark, some memory of it remains and affects the field evaluation code in some way. If you have a bookmark called abc then you should be able to use { IF abc = 1 "T" "F" } So in the case where { MERGEFIELD xyz } resolves to abc and you use { IF { MERGEFIELD xyz } = 1 "T" "F" } it looks as if Word is doing an extra dereference. However, I'm not sure it behaves consistently. { = } fields should also work with bookmarks without having to wrap them up as { abc } or { REF abc }. However, because the rules have never been particularly clear and the documentaiton didn't keep up when MERGEFIELD fields came in (around Word 2 I think), it's always been difficult to know what exactly to rely on. All I can say is that in my experience, quoting MERGEFIELD fields when you are doing text comparisons works more reliably than not quoting them. OTOH if you know that a { MERGEFIELD } result can never be the same as any bookmark names in your document, you're probably OK. There's one place where using { MERGEFIELD } fields causes problems but it only seems to occur when you also have a SKIPIF field in the Mail Merge Main Document (again, I would have to guess that the code is old and something goes back to pre-MERGEFIELD days). (pre-MERGEFIELD, you could only really have WOrd data sources and the columns in the data source were treated as bookmarks, e.g. you just used { mycolumnname } or { REF mycolumnname } to insert the value. In fact you can still do it, but only if the data source is read via a built-in converter (e.g. .doc, .rtf) or comes in via an external converter. Peter Jamieson > Thank you very much. You would think that I would have tried placing > quotes [quoted text clipped - 70 lines] >> > escape >> > character? Or is anyone else even able to duplicate this? I don't mean to look a gift horse in the mouth, but I thought as informed as you are you might want all the information. Just for fun again, I took the Text Variations document that I was using for my bookmarks. I then made a bookmark with a name of RET_Any, and changed my .csv datafile to include a datarow with AdmitType populated with RET_Any, Evaluated the MERGEFIELD against RET_Any with no quotes around the MERGEFIELD identifier. The code produced "test" as if it were working like I originally expected. No need for the quotes. Unlike when we used just RET. > > It would still interest me to have a full explanation, if you can explain > > it [quoted text clipped - 112 lines] > >> > escape > >> > character? Or is anyone else even able to duplicate this? You really have to think about what you are actually testing when you explore this area. a. The relationship between the value of AdmitType and the value of RET_Any can have (at least) the following logically different patterns: 1. bookmark RET_Any does not exist 2. bookmark RET_Any esists and has value "RET_Any" (This wouldn't be a special case if you were using a traditional procedural language) and a. AdmitType = "RET_Any" b. AdmitType = "XXX" 3. bookmark RET_Any esists and has value "XXX" and a. AdmitType = "RET_Any" b. AdmitType = "XXX" c. AdmitType = "YYY" You can then have IF statements of the form w. { IF operand1 = operand2 "T" "F" } x. { IF operand1 = "operand2" "T" "F" } y. { IF "operand1" = operand2 "T" "F" } z. { IF "operand1" = "operand2" "T" "F" } Where the operand is quoted, its result is always treated as a string. However, where the operand is not quoted, it will probably be treated as a bookmark name, if there is a bookmark with that name. So for example if AdmitType is XXX then any of the following evaluate as "T" regardless of the existence or value of RET_Any: { MERGEFIELD AdmitType } = XXX { MERGEFIELD AdmitType } = "XXX" "{ MERGEFIELD AdmitType }" = XXX "{ MERGEFIELD AdmitType }" = "XXX" However, if RET_Any exists and is "XXX" then { MERGEFIELD AdmitType } = RET_Any and "{ MERGEFIELD AdmitType }" = RET_Any will also evaluate as "T" but { MERGEFIELD AdmitType } = "RET_Any" and "{ MERGEFIELD AdmitType }" = "RET_Any" will evaluate to "F" If AdmitType is RET_Any, then { MERGEFIELD AdmitType } = RET_Any will always evaluate to "T" (because if there is no bookmark called RET_Any, then both values are treated as the string "RET_Any", but if there is a bookmark called RET_Any, then both values are treated as the bookmark, so have the same value anyway. But if for example the value of RET_Any is "XXX", then { MERGEFIELD AdmitType } = XXX and { MERGEFIELD AdmitType } = "XXX" will evaluate to "T" (XXX and "XXX" are treated as strings, but { MERGEFIELD AdmitType } is unquoted, evaluates to the name of a bookmark, whose /value/ is compared with "XXX" "{ MERGEFIELD AdmitType }" = XXX and "{ MERGEFIELD AdmitType }" = "XXX" evaluate to "F", because XXX and "XXX" are treated as the string "XXX" and "{ MERGEFIELD AdmitType }" is treated as the string "RET_Any" In the "special" situation where RET_Any is set to "RET_Any", then { MERGEFIELD AdmitType } = RET_Any { MERGEFIELD AdmitType } = "RET_Any" "{ MERGEFIELD AdmitType }" = RET_Any "{ MERGEFIELD AdmitType }" = "RET_Any" will all evaluate to true. Not sure if even that is the complete story, but there you go! Peter Jamieson >I don't mean to look a gift horse in the mouth, but I thought as informed >as [quoted text clipped - 150 lines] >> >> > escape >> >> > character? Or is anyone else even able to duplicate this? Hi Michael (& Peter). Have a look at this thread to see if it's relevant: http://groups.google.co.uk/group/microsoft.public.word.mailmerge.fields/browse_t hread/thread/9dd85f3a03f23f13/0b8333707ffd46e4?lnk=st&q=&rnum=1&hl=en#0b8333707f fd46e4 Be warned - it's a tad lengthy :-) Cheers. Ed > Thank you very much. You would think that I would have tried placing quotes > around the MERGEFIELD identifier, but I hadn't. [quoted text clipped - 60 lines] > > > escape > > > character? Or is anyone else even able to duplicate this? > Be warned - it's a tad lengthy :-) But it ended up succinct :-) Peter Jamieson > Hi Michael (& Peter). > [quoted text clipped - 87 lines] >> > > escape >> > > character? Or is anyone else even able to duplicate this? Hi Peter, > But it ended up succinct :-) It did! .................................................................................. Eventually. Regards. Ed > > Be warned - it's a tad lengthy :-) > [quoted text clipped - 92 lines] > >> > > escape > >> > > character? Or is anyone else even able to duplicate this? 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. > Try > [quoted text clipped - 42 lines] > > escape > > character? Or is anyone else even able to duplicate this? 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 > 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 [quoted text clipped - 70 lines] > > > escape > > > character? Or is anyone else even able to duplicate this? can this if be inserted as a nested if as { IF "{ MERGEFIELD contact person }" = "blank" "cancel print" } or something similar. My object is if the merge macro finds a blank cell in the excel sheet. I want it to, cancel the printout at that point. Have not done this in word. Any Help I am thankful for Thanks > Try > [quoted text clipped - 42 lines] > > escape > > character? Or is anyone else even able to duplicate this? You would do better posting your own questions in appropriate forums rather than appending them to a variety of others scattered across the Word forums. Please do not multi-post. If you wish to post to more than one newsgroup, then put all the groups in the same 'send-to' line separated by commas. This links the messages and minimizes duplication of effort by those who respond to questions. You cannot stop a merge by inserting conditional fields into the merge document. If you want to perform a partial merge then edit your data source or filter the record set to give the results you require.  Signature<>>< ><<> ><<> <>>< ><<> <>>< <>><<> Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org <>>< ><<> ><<> <>>< ><<> <>>< <>><<> > can this if be inserted as a nested if as { IF "{ MERGEFIELD contact > person }" = "blank" "cancel print" } [quoted text clipped - 52 lines] >>> escape >>> character? Or is anyone else even able to duplicate this? I was looking when I posted to this your statement at end answered what I was trying to do. Thank You > You would do better posting your own questions in appropriate forums rather > than appending them to a variety of others scattered across the Word forums. [quoted text clipped - 63 lines] > >>> escape > >>> character? Or is anyone else even able to duplicate this? |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.