\* MERGEFORMAT and \* Charformat

[Jose Valdes]

The following format switches are giving me inconsistent results in MS Word
2003: \* MERGEFORMAT and \* Charformat.

I use two character styles, 2400 and 3000, based on product model numbers to
hide and show text. For example, if I print the 2400 manual, I format the
3000 character style as hidden text. The problem is that if I apply a
character style to a cross-reference (ref field), the ref does not
consistently keep the character style when the result of the field changes.
For example, if the result of the ref is "Product", only part of the result
of the ref field keeps the character style when it changes to something
longer like "Product Information". Maybe the word Product will keep the
character style, but Information will not.

Another annoyance of Charformat is that if I change which character style is
hidden and which is shown, some ref fields lose the character style. I know
that I have seen this problem with Charformat, but I'm not sure about
MERGEFORMAT.

Does anyone know how to get one or both of these format switches to work
properly? I feel like I am using these switches exactly as they are
documented by Microsoft.

Currently, I use MERGEFORMAT exclusively and I re-apply character styles to
ref fields when they change their values. Unless I can get these switches to
work properly, I plan to write a VBA script that will automate re-applying
these formats.
Thanks! Jose

 

[Graham Mayor]

Personally I don't use Mergeformat at all. Either I use no switch and format
the field as required or add a charformat switch if needed.
You haven't provided sufficient information to duplicate the conditions at
your end, but from your description it appears that the field is not
updating. You may be better employed adding a macro to force an update - Try
the sample code at http://www.gmayor.com/installing_macro.htm

--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP


<>>< ><<> ><<> <>>< ><<> <>>< <>><<>

 

[Jose Valdes]

Graham,

I am sorry that I did not provide enough information for you. I spent
considerable time trying to provide enough information without turning this
message into a book. Hopefully, I'll do better this time around. ;-)

I also avoid using MergeFormat and CharFormat unless necessary, and in this
case it is absolutely necessary. When you update a REF field that uses
neither switch, it drops all direct formatting and character styles, but it
assumes the formatting of the paragraph style. In this case, I am using a
character style to hide some content, and another character style to show
some other content. If the REF field does not retain the character style,
text that I want to hide might be visible.

Here are the steps to recreate the problem with \* CharFormat
-Create a new character style.
-Add the \* CharFormat switch to a REF field
-Apply character style to the 'R' in REF field.
-Modify character style to be hidden text.
-Update the REF field

If you have successfully recreated the problem the REF field will be visible
instead of invisible. Like all truly perplexing problems, this one only
appears when it can cause me the most pain. I won't be surprised if you come
back with the standard Microsoft answer, "It works when I try it". ;-)

Here are the steps to recreate the \* MergeFormat problem:
-Create a new character style.
-Modify character style to be hidden text.
-Apply the character style to a REF field that displays the text of a
bookmark.
-MS Word automatically applies the MergeFormat switch to the REF field (if
it didn't have it already)
-The REF field disappears.
-Change the value of the bookmark (used by REF) to be something
significantly longer than its original value such as going from "Product" to
"Product Information Regarding Useless Warnings"
-Update the REF field.

If you have successfully recreated the problem, the first half of the REF
field is hidden, but the second half is visible.

By the way, if no one has a solution to these bizarre problems, I won't
fault the expert knowledge of this very helpful community. Some problems are
just too weird for even the smartest of newsgroups. ;-)
I have resigned myself to creating a VBA script that will reformat these
nasty REF fields before going to print.

Thanks!
Jose

 

[Peter Jamieson]

Yes, when you start using the hidden attribute with fields, things can be
very perplexing.

For \*Mergeformat, the problem is that Word Help no longer really describes
what the switch actually does, and I think a lot of people, probably even
Microsoft developers, have been led to believe by the name of the switch
into thinking that it does something that it does not. I believe that this
is why Word keeps trying to apply the \*Mergeformat switch to fields and why
most people just want to get rid of it wherever it appears.

\*Mergeformat applies the format of the previous result, on a word-by-word
basis (using whatever Word thinks is a "Word" in this case). In the example
you describe, applying Hidden to the field means that the existing words are
hidden. But if you add a word to the end of the source (say it's a SET
field) and re-execute the REF, the new Word is formatted as per the
surrounding paragraph. So if you do

{ SET X "1 2" }
{ REF X \*Mergeformat }

Update the fields, then select the REF field and format it as hidden text.
The field disappears

Change the SET field to be

{ SET X "1 2 3" }

Update the fields. The REF field should display a "3". If you display the
field codes, select the field and look at Format|Font, you will probably see
that the Hidden checkbox is greyed, i.e. in its "some of it is hidden"
state. If you re-apply Hidden to the whole field and update it, the "3"
disappears. I don't think it makes a difference whether you use direct
formatting or a Character format in this case.

So Mergeformat isn't going to do what you want.

However, the situaiton with \*Charformat is rather different.

<<
If you have successfully recreated the problem the REF field will be visible
instead of invisible. Like all truly perplexing problems, this one only
appears when it can cause me the most pain. I won't be surprised if you come
back with the standard Microsoft answer, "It works when I try it". ;-)
It works when I try it But I agree that the behaviour does not seem
consistent.

Some observations...
a. When I modify the character format, Word stuffs a \*MERGEFORMAT into any
fields that happen to be selected that use the character format (and I'm not
even completely sure it's as simple as that). Although you can probably
avoid that programmatically, this kind of "behaves one way when it's
selected" behaviour is not helpful and could well be one reason why your
results are inconsistent.
b. If I actually just select the R of REF and format it, when the
formatting is "Hidden text", what actually tends to happen is that Word
thinks the field is { EF mybookmark \*Charformat } and displays an error
that there's no such bookmark (unless you happen to have a bookmark called
EF. I
c. If I select the space before the R of REF and format that, the
\*Charformat works, except that (a) still applies. Again this goes back to
the original Word processing of fields where you were supposed to format the
/first/ character in the field code. However, that was in the days when Word
did not by default put a space after the opening brace. But I've never got
this "formatting the space but not the first letter of the field code" thing
to behave entirely consistently either. I'd apply the character format to
the whole field - that seems to work, and I'm not sure why you /wouldn't/ do
it unless for example it affected the way you found fields programmatically.
But you still get problem (a).

There's probably more, but for now, do you think that the problems you see
could all be explained by the description of Mergeformat and charformat
problem (a)?

Peter Jamieson

 

[Jose Valdes]

Thank you very much for your reply. I was using CharFormat as it was
documented, which is only formatting the R. I just experimented with
formatting the entire field, but carefully deleting the MergeFormat switch
that MS Word so helpfully inserts. ;-) I couldn't get it to break. So far,
so good. That doesn't necessarily mean that CharFormat will work
consistently for me from now on, but it worked well enough that I'm willing
to give it another try before diving into VBA to build a fix.

Thanks! Jose