Mailmerging to trim a table

[Walter Briscoe]

I have a questionnaire in a .doc which consists of a table:
A typical sequence of table rows is:

4.1 Were there toilets? Yes No goto 5.1
4.2 Were the toilets open? Yes No
4.3 Were the toilets clean? Yes No
5.1 Were there street lights? Yes No

I have a .xls data file which for our purposes can be considered to be
toilets
Yes

or
toilets
No

So, I start knowing the answer to 4.1.
If the answer is Yes, I want to highlight that answer in some fashion.
(With pen and paper, I would use a pen to circle the answer, bold would
satisfy my need when using printer and paper.)
If the answer is No, I want to highlight No and delete rows 4.2 and 4.3.

I could easily, if tediously, use if to empty those rows.
I want to make them vanish. So I would end up:

4.1 Were there toilets? No goto 5.1
5.1 Were there street lights? Yes No


Any suggestions as to how I might do this?

 

[Peter Jamieson]

Any suggestions as to how I might do this?

It depends partly on what "this" is. if it's the entire problem, then
there's the question of how you access your Excel file during the merge when
it's not the data source for the merge. Personally, I would always try to
construct the data source I needed to make the merge easy, but you may not
be in a position to do that.

If it's more a question of how to eliminate those rows, I would consider a
twostage or even three-stage merge which
a. created a table row in a mailmerge output document for each input row,
but either filled in a column with the answer, or did that /and/ filled in a
column with Y for "there was an answer" and N for "there was no answer".
b. do a second merge using your output as the data source, and use the
Advanced query options to eliminate rows where the answer is blank or that
extra column had "N".

But I suspect it is not that simple...

The highlight should be doable using an IF field whose true/false result
texts are highlighted (e.g. bolded)/not highlighted as appropriate. However,
you could also consider using an oval autoshape, with the text Yes in it,
whose layout is set to be "inline with text" as one of the result texts of
an IF statement. I haven't tried it as part of a merge or in tabular output,
but the IF looks like

{ IF condition "{ SHAPE \*MERGEFOMAT }" "false-text" }

after you have cut/copied-pasted the shape into the IF field. (You may need
to switch off the "Automatically create drawing canvas when inserting
autoshapes" option before this has any chance of working).

 

[Doug Robbins - Word MVP]

Mail merge is probably not the best tool to use for this purpose. Just what
do you have in the Excel file?

--
Hope this helps.

Please reply to the newsgroup unless you wish to avail yourself of my
services on a paid consulting basis.

Doug Robbins - Word MVP

 

[macropod]

Hi Walter,

In Essence, what you need is an IF test to test your field's Yes/No value and output the additional two rows only if the field
contains 'Yes'. Such a field might be coded along the lines of:

{IF{MERGEFIELD ToiletsExist \* Upper}= "Y*" "
|4.2 Were the Toilets Open? {MERGEFIELD ToiletsOpen \* Lower \* Caps}.|
|4.3 Were the Toilets Clean? {MERGEFIELD ToiletsClean \* Lower \* Caps}.|"}

where the '|' characters delineate your table rows. Since you can't have just part of a table in a mergefield, these extra two rows
would actually constitute a separate table. With careful formatting, however, the breaks between the tables needn't be noticeable in
the merged output.

Note that the field braces indicated for the coding (ie '{}') must be created in pairs via Ctrl-F9.

 

[Walter Briscoe]

In message <#[email protected]> of Mon, 14 Jul 2008
17:56:54 in microsoft.public.word.mailmerge.fields, Peter Jamieson

Any suggestions as to how I might do this?

It depends partly on what "this" is. if it's the entire problem, then
there's the question of how you access your Excel file during the merge
when it's not the data source for the merge. Personally, I would always
try to construct the data source I needed to make the merge easy, but
you may not be in a position to do that.
[snip]

{ IF condition "{ SHAPE \*MERGEFOMAT }" "false-text" }

after you have cut/copied-pasted the shape into the IF field. (You may
need to switch off the "Automatically create drawing canvas when
inserting autoshapes" option before this has any chance of working).

I have gone away for a while before replying to all the help offered in
this thread. I am grateful to Peter Jamieson, on whose response I am
hanging this replay, and also to Doug Robbins and macropod for their
responses.

I gave up on shapes because the shape would be part of the table rather
than "on" the table.

I created a file of bookmarks to merge. Assuming my fieldname is
toilets, I had bookmarks no_4_1 and yes_4_1

Where no_4_1 consists of
4.1 Were there toilets? yes NO GOTO 5.1

and yes_4_1 consists of
4.1 Were there toilets? YES no goto 5.1
4.2 Were the toilets open? Yes No
4.3 Were the toilets clean? Yes No

(I use CAPITALS above to mimic BOLD and plain text in the actual file.)

{ INCLUDETEXT "enclosures" { MERGEFIELD toilets }_4_1 } resulted in an
invalid bookmark. { MERGEFIELD toilets } is evaluated as yes or no but
the total thing does not seem to be rescanned to produce a bookmark.

I have had to type this as the clipboard gets the expression's value
rather than the expression. I found I had to do something like:
{IF {MERGEFIELD toilets} = "yes" "{INCLUDETEXT "enclosures" yes_4_1}" "{INCLUDETEXT "enclosures" no_4_1}" }

I get a blank line on the output document for the algebra and the value
of the algebra but can live with the unwanted blank line.

So, I have something which works without achieving the beauty I would
like. Thanks again and I remain open to suggestion.

I had tried putting the question in the enclosing file, but that led me
to cells with more text than the space available to show it and
scrolling did not work.

I hope the above is not too unclear. It is as clear as I can currently
put it.

 

[Peter Jamieson]

{ INCLUDETEXT "enclosures" "{ MERGEFIELD toilets }_4_1" }

should do it, but since the official syntax for the bookmark name doesn't
surround it by quotes, and since Word sometimes seems to lose them, it might
be better to use

{ INCLUDETEXT "enclosures" { QUOTE { MERGEFIELD toilets }_4_1 } }

I get a blank line on the output document for the algebra and the value of
the algebra but can live with the unwanted blank line.

Not sure what you mean here, but if you are bookmarking the paragraph
markers at the ends of your lines/blocks, they will end up in the output as
well. Better to display all the formatting characters before you insert your
bookmarks.

--
Peter Jamieson
http://tips.pjmsn.me.uk

In message <#[email protected]> of Mon, 14 Jul 2008
17:56:54 in microsoft.public.word.mailmerge.fields, Peter Jamieson

Any suggestions as to how I might do this?

It depends partly on what "this" is. if it's the entire problem, then
there's the question of how you access your Excel file during the merge
when it's not the data source for the merge. Personally, I would always
try to construct the data source I needed to make the merge easy, but you
may not be in a position to do that.
[snip]

{ IF condition "{ SHAPE \*MERGEFOMAT }" "false-text" }

after you have cut/copied-pasted the shape into the IF field. (You may
need to switch off the "Automatically create drawing canvas when inserting
autoshapes" option before this has any chance of working).

I have gone away for a while before replying to all the help offered in
this thread. I am grateful to Peter Jamieson, on whose response I am
hanging this replay, and also to Doug Robbins and macropod for their
responses.

I gave up on shapes because the shape would be part of the table rather
than "on" the table.

I created a file of bookmarks to merge. Assuming my fieldname is toilets,
I had bookmarks no_4_1 and yes_4_1

Where no_4_1 consists of
4.1 Were there toilets? yes NO GOTO 5.1

and yes_4_1 consists of
4.1 Were there toilets? YES no goto 5.1
4.2 Were the toilets open? Yes No
4.3 Were the toilets clean? Yes No

(I use CAPITALS above to mimic BOLD and plain text in the actual file.)

{ INCLUDETEXT "enclosures" { MERGEFIELD toilets }_4_1 } resulted in an
invalid bookmark. { MERGEFIELD toilets } is evaluated as yes or no but the
total thing does not seem to be rescanned to produce a bookmark.

I have had to type this as the clipboard gets the expression's value
rather than the expression. I found I had to do something like:
{IF {MERGEFIELD toilets} = "yes" "{INCLUDETEXT "enclosures" yes_4_1}"
"{INCLUDETEXT "enclosures" no_4_1}" }

I get a blank line on the output document for the algebra and the value of
the algebra but can live with the unwanted blank line.

So, I have something which works without achieving the beauty I would
like. Thanks again and I remain open to suggestion.

I had tried putting the question in the enclosing file, but that led me to
cells with more text than the space available to show it and scrolling did
not work.

I hope the above is not too unclear. It is as clear as I can currently put
it.

 

[Walter Briscoe]

In message <[email protected]> of Mon, 21 Jul 2008
15:49:43 in microsoft.public.word.mailmerge.fields, Peter Jamieson

{ INCLUDETEXT "enclosures" "{ MERGEFIELD toilets }_4_1" }

should do it, but since the official syntax for the bookmark name
doesn't surround it by quotes, and since Word sometimes seems to lose
them, it might be better to use

{ INCLUDETEXT "enclosures" { QUOTE { MERGEFIELD toilets }_4_1 } }

Peter,
Thanks again for your effort.

None of that is effective. Instead of doing the inclusion, the words
{ INCLUDETEXT "enclosures" "yes_4_1" } or
{ INCLUDETEXT "enclosures" "no_4_1" } are written to the output file.
The literalizing effects of QUOTE, etc. seem to apply to the including
directive.

Not sure what you mean here, but if you are bookmarking the paragraph
markers at the ends of your lines/blocks, they will end up in the
output as well. Better to display all the formatting characters before
you insert your bookmarks.

I checked and was not (by luck) bookmarking those markers.
I think the marker at the end of the line containing the {INC...}
directive is being written because, if I do
{INC...}
{INC...}
two blank lines are written but if I do
{INC...}{INC...}
only one is written.

I know of no method of doing { INC... } [ TABLE ]

I had a problem which I solved.
I had included 3 characters such as ABC in fonts Tahoma, Wingdings, and
Tahoma respectively. The Wingdings character was transformed to a small
open square which suggested it could not be rendered. The problem went
when I removed "/* MERGEFORMAT" from my INCLUDETEXT directives.
(Microsoft had automatically included that switch when it created the
directives for me.)

 

[Peter Jamieson]

I'm assuming you're using field braces (ctrl-F9) for /all/ the {}, otherwise
I don't think your own examples would have worked.

However, you may find that the { INCLUDETEXT } fields are preserved in the
output document and that you need to press Alt-F9 (and possibly even select
the document and press F9) to see their results.

I checked and was not (by luck) bookmarking those markers.
I think the marker at the end of the line containing the {INC...}
directive is being written because, if I do

Ah, yes, anything outside the { INCLUDETEXT } field (or any other type of
field) will be included in the output.

You can either follow the INCLUDETEXTs one after the other without spaces,
or, if you want to lay your Mail merge Main Document out in a more readable
way, you can include new paragraph marks inside the fields, like this:

{ INCLUDETEXT blah...
}{ INCLUDETEXT blah...
}{ INCLUDETEXT blah...

(The main drawback of this is that when you switch from "field codes" view
to "results" view in a long Mail Merge Main document, Word typically has to
repaginate and so on)

I know of no method of doing { INC... } [ TABLE ]

There will always be a paragraph mark between the field and the table. In
the general case you cannot really mix the two up successfully. You can
however, bookmark bits of table in your included document and include those
via INCLUDETEXT - I am not sure if that would help in this case.

when I removed "/* MERGEFORMAT" from my INCLUDETEXT directives. (Microsoft
had automatically included that switch when it created the directives for
me.)

Yes, in certain circumstances Word will re-inser them too, so be careful!

If you want, you can despam my email - remove the KillMapS from
(e-mail address removed) , zip up what you have and e-mail it to me
and I'll see if I can spot any opportunities for improvement.

--
Peter Jamieson
http://tips.pjmsn.me.uk

In message <[email protected]> of Mon, 21 Jul 2008
15:49:43 in microsoft.public.word.mailmerge.fields, Peter Jamieson

{ INCLUDETEXT "enclosures" "{ MERGEFIELD toilets }_4_1" }

should do it, but since the official syntax for the bookmark name doesn't
surround it by quotes, and since Word sometimes seems to lose them, it
might be better to use

{ INCLUDETEXT "enclosures" { QUOTE { MERGEFIELD toilets }_4_1 } }

Peter,
Thanks again for your effort.

None of that is effective. Instead of doing the inclusion, the words
{ INCLUDETEXT "enclosures" "yes_4_1" } or
{ INCLUDETEXT "enclosures" "no_4_1" } are written to the output file. The
literalizing effects of QUOTE, etc. seem to apply to the including
directive.

Not sure what you mean here, but if you are bookmarking the paragraph
markers at the ends of your lines/blocks, they will end up in the output
as well. Better to display all the formatting characters before you insert
your bookmarks.

I checked and was not (by luck) bookmarking those markers.
I think the marker at the end of the line containing the {INC...}
directive is being written because, if I do
{INC...}
{INC...}
two blank lines are written but if I do
{INC...}{INC...}
only one is written.

I know of no method of doing { INC... } [ TABLE ]

I had a problem which I solved.
I had included 3 characters such as ABC in fonts Tahoma, Wingdings, and
Tahoma respectively. The Wingdings character was transformed to a small
open square which suggested it could not be rendered. The problem went
when I removed "/* MERGEFORMAT" from my INCLUDETEXT directives. (Microsoft
had automatically included that switch when it created the directives for
me.)

 

[Walter Briscoe]

In message <[email protected]> of Tue, 22 Jul 2008
18:32:44 in microsoft.public.word.mailmerge.fields, Peter Jamieson

I'm assuming you're using field braces (ctrl-F9) for /all/ the {},
otherwise I don't think your own examples would have worked.

I am. I have found the copy and paste - say from an HTML document - is
ineffective. The field braces seem to act as an outward effect of some
hidden internal stuff.

However, you may find that the { INCLUDETEXT } fields are preserved in
the output document and that you need to press Alt-F9 (and possibly
even select the document and press F9) to see their results.

I tried that and it works. Effectively, the mailmerge generates an
INCLUDETEXT in the output document which is scanned in response to
Alt-F9. The inability to cause that second scan to happen looks bad to
me. I found { if 1 = 1 { INCLUDETEXT ... } } works. (The token-delimiter
spaces in "1 = 1" are needed as "1=1" results in an error.)

Ah, yes, anything outside the { INCLUDETEXT } field (or any other type
of field) will be included in the output.

You can either follow the INCLUDETEXTs one after the other without
spaces, or, if you want to lay your Mail merge Main Document out in a
more readable way, you can include new paragraph marks inside the
fields, like this:

{ INCLUDETEXT blah...
}{ INCLUDETEXT blah...
}{ INCLUDETEXT blah...

That is NOT something I want to do.

(The main drawback of this is that when you switch from "field codes"
view to "results" view in a long Mail Merge Main document, Word
typically has to repaginate and so on)

I know of no method of doing { INC... } [ TABLE ]

That saves me fruitlessly searching.

There will always be a paragraph mark between the field and the table.
In the general case you cannot really mix the two up successfully. You
can however, bookmark bits of table in your included document and
include those via INCLUDETEXT - I am not sure if that would help in
this case.

That is what I do.

Yes, in certain circumstances Word will re-inser them too, so be careful!

05h1t !!

If you want, you can despam my email - remove the KillMapS from
(e-mail address removed) , zip up what you have and e-mail it to
me and I'll see if I can spot any opportunities for improvement.

That is EXTREMELY kind. I have recently introduced a black vertical
strip for no reason obvious to me. I am hoping the reason will jump out
at you. It is probably best if any lessons appear here so other
newsgroup readers can benefit.