Paragraph Mark in an if-then-else field (2000 (9.0.3821 SR-1))

Topic

New Reply

I’m trying to set up a merge document so that if a field is not blank, a paragraph mark will be inserted. That seems straightforward enough, but my merge document is a table, and when I enter the “if…then…else” field, it puts a new row in the table (which is very bad, because the field is in one column, and the row it inserts is the width of the entire table).

Is there a code I should be inserting instead of just pressing the “enter” key in the “insert this text” field of the “if…then…else” dialog box? Or is there something else I’m just not thinking of?

Thanks.

Reply | Quote

Replies

UPDATE:

I tried performing the merge to see what the output would look like. What appeared to be a new row was the result of the merge fields being too large for the column width. After merging, there was no new row, and all the data was in the correct column. In other words, it worked the way it was supposed to.

BUT the text doesn’t wrap, or even scroll. It seems to disappear under the next column to the right. The right indent indicator for the cell is fine.

I am becoming more and more perplexed. (By “perplexed” I mean “apoplectic” but I’m trying to be polite. )

Thanks.

Reply | Quote

Anne

Can you post a sample of what you are trying to do? I can’t picture the part about inserting table rows. Is this conditional on the result or does it happen in both cases of the condition?

Reply | Quote

I took some screen shots to illustrate what I’m trying to describe. This one is of the merge “master” document.

I appreciate your help.

Reply | Quote

Here’s screen shot #2 (also of the merge “master” document).

Reply | Quote

This last screen shot is of the merged document, showing how the text won’t wrap within the cell.

Reply | Quote

Anne, have you checked the table properties; specifically the cell and row properties to make sure you don’t have the height and width sizes marked as “exactly” instead of either “auto” or “at least”? I admit that this would make more sense if the text were wrapping to the right margin of the cell, but disappearing at the bottom, but it won’t hurt to check.

You might also try resetting the formatting of the cell to Normal, to make sure some other unidentified formatting isn’t influencing this behavior.

Reply | Quote

Excellent suggestion, Samantha. Unfortunately, when I checked the table properties, everything seems to be set correctly.

Interestingly, you can see in the attached screenshot that when I highlight the cell, it actually does seem to run beneath the cell to its right.

I’ve decided that there is no solution to this problem and that the workaround will be to manipulate the merged document. (Big sigh.)

Thanks for your help.

Reply | Quote

Hi Anne,
It looks to me like the text being referenced by the mergefield statement might itself be a table or a cell thereof. That would produce the behaviour you’re seeing, because Word would be trying to insert a whole cell or table in its original format.

What you need to do in that case is to either:
a) convert the source material to a text format instead of a table format; or
bookmark the text in each cell (not including the cell markers) in the source table and reference the bookmarks in your mergefield statement

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

The cell is composed of a series of eight word fields (if…then…else statements) and merge fields. Paraphrased example:
{If mergefield “X” is not blank, insert hard return} {mergefieldX}{If mergefield “Y” is not blank, insert hard return} {mergefieldY}{If mergefield “Z” is not blank, insert hard return} {mergefieldZ} etc.

The idea is that if X, Y, and Z all contain data, each set of data will display on a new line instead of running together, like this:

The data from X
The data from Y
The data from Z

instead of

The data from X The data from Y The data from Z

I’m merging from an Access database. There are no other Word tables involved. Each merge field represents the data in a separate cell in the Access table.

I’m afraid I don’t understand your suggestions about manipulating the source material (converting it to text or bookmarking it). Could you explain it further?

Thanks.

Reply | Quote

Hi Anne:
Have you enclosed your THEN & ELSE statements in quotes. I find that Word sometimes gets confused without them. The field code syntax for what you describe would be:

{ IF { MERGEFIELD X } “” “P{ MERGEFIELD X }” “” }{ IF { MERGEFIELD Y } “” “P{ MERGEFIELD Y }” “” }{ IF { MERGEFIELD Z } “” “P{ MERGEFIELD Z }” “” }

where P represents a paragraph mark. I’ve attached a zip file to illustrate, but I’m afraid I used a Word document as a datasource, so that might make a difference.
Hope this helps,

Reply | Quote

Hi Anne,

Regarding “suggestions about manipulating the source material”, I was working from the premise that your merge was from a table in another Word document, because that was the only way I could reproduce the behaviour of part of the merged field disappearing under the adjacent column in the table. I can’t help you if that’s what merging from Access is doing.

As for inserting paragraph marks, that’s relatively straightforward – Phil’s already offered one solution, attached is another, with some extra tweaks you might find useful.

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Hi macropod:
I always find your solutions interesting. I have a few questions. I notice that you’ve used set & quote fields.

1. I understand that the SET field was just for demonstration purposes only without having to do a merge (very clever). What advantages do you find the QUOTE fields have, if any, over using mergefields directly?
2. Do you find any advantage to use the character numbers (09,11,) over using tabs, linefieeds, & para marks directly?
3. I notice that you can insert tabs & linefeeds using the character numbers & the quote field, but not paragraph marks. Is that correct?

Thanks,

Reply | Quote

Hi Phil,

The main purposes I have for QUOTE fields are:
a) acting as a wrapper for various fileds that I want to force to update together; and
outputting ASCII characters.
The latter can also be done with a SYMBOL field, but SYMBOL doesn’t output the same range of characters as QUOTE. QUOTE can also handle many ASCII characters per field, but SYMBOL only handles one character per field.

As for using QUOTE with MERGEFIELD, I think that can sometimes overcome problems where the mergefiled is a delimted numeric or alpha-numeric string. From memory, if you try to do an IF test on such a string, Word ignores the text and does math with the numeric part. Again from emory, wrapping the mergefiled result in quotes before processing it is another way of overcoming this odd behaviour.

Also, I find that using QUOTE to output characters such as a hard space (160) is easier to work with than typing a quote character, inserting a hard space, then typing another quote character. The attachment to my last post demonstrated a mix of both techniques.

As for para marks, {QUOTE 13} returns “Error! Cannot insert return character.” So, even though Word knows what you want, it won’t let you have it. Which is strange considering that {QUOTE 09} outputs a tab, {QUOTE 11} outputs a linefeed, {QUOTE 12} outputs a page break and {QUOTE 14} outputs a column break.

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Thanks for this explanation. I haven’t worked much with the QUOTE field, but I’m beginning to see uses for it. I intend to study some of the other posts that you’ve had using the field. I seem to recall you mentioning that the QUOTE field will either update automatically or will update another field automatically. I haven’t found this to be so, but will re-read your other posts.

Reply | Quote