Latent Merge Fields

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Ken - 13 Oct 2004 23:35 GMT

A main docunment is created with Word 2003 mailmerge automation. Before
saving the document, its converted from a mailmerge 'Letter' to a 'Normal
Word Document' using the Main Document Setup icon on the mailmerge toolbar.

The associated query is removed from the document and all mailmerge fields
are instantiated, except those in headers.

Why are the merge field references not removed from a header?

This problem does not occur on all of our customer's workstations. Some of
the Office 2003 installations remove all merge field references when 'Normal
Word Document' is selected with the Main Document Setup.

Thanks for your help with this problem.

Reply to this Message

Ken - 15 Oct 2004 02:59 GMT

The Mergefields are reintroduced in the header when the document is printed
or prrint previewed. This occurs at all workstations.

> A main docunment is created with Word 2003 mailmerge automation. Before
> saving the document, its converted from a mailmerge 'Letter' to a 'Normal
[quoted text clipped - 10 lines]
>
> Thanks for your help with this problem.

Reply to this Message

Peter Jamieson - 15 Oct 2004 09:31 GMT

What happens is that when you convert to a Normal Word Document, all that
happens is that the data source and any filter and sort specifications are
removed. All the merge field are actually still there, and their "preview"
results will show the values of the data source record that was current at
the time the conversion occurred.

If you get to that point, then e.g. select any of the fields and press F9,
you will see the field's name displayed in chevrons (exactly what you see
may depend on other settings in Tools|Options|View).

When you print or preview, some field types in some parts of the document
are automatically executed and others are not. The settings
Tools|Options|Print|Update fields and possibly Tools|Options|Print Update
links may have a bearing on this (i.e. I am guessing that that may be the
source of the differences on your customer's systems). In this case, the
ones in the header/footer are executed and you see the chevron versions cf.
when you press F9.

If you want to see the /results/ and never the chevron versions, I suggest
you do e.g.

Dim oStoryRange As Range
For Each oStoryRange In ActiveDocument.StoryRanges
oStoryRange.Fields.Unlink
Next

If you want to see the chevron versions only, perhaps

Dim oStoryRange As Range
For Each oStoryRange In ActiveDocument.StoryRanges
oStoryRange.Fields.Execute
Next

will work (I haven't tried). I don't know how you could leave the chevron
versions but display the preview results.

Signature

Peter Jamieson

Reply to this Message

Ken - 18 Oct 2004 14:59 GMT

Peter,

Thanks for sharing your extensive insght. I ran your first code fragment,
because I want to permanmently remove the mergefield references and leave
only the "resilts" in the document.

After executing the code, all of the references were removed from the main
text - I gather this is true because I could no longer display the chevron
versions with Word's "View Merged Data' button.

Except those merge fields in the document's header. These merge fields were
not unlinked.

I ran the code against the document in mege Letter form, before converting
to a 'Normal Word Document'.

The ActiveDocument.StoryRanges.Count is 5. And the StoryRanges.StoryType's are

wdMainTextStory
wdFootnoteSeparatorStory
wdFootnoteContinuationSeparatorStory
wdEndnoteSeparatorStory
wdEndnoteContinuationSeparatorStory

Shouldn't there be a wdPrimaryHeaderStory in that collectiion for this
document? Is that why the merge fields are not unlinked rom the header? As
usual I'm confused.

Thanks for you help,

Ken

> What happens is that when you convert to a Normal Word Document, all that
> happens is that the data source and any filter and sort specifications are
[quoted text clipped - 48 lines]
> >
> > Thanks for your help with this problem.

Reply to this Message

Ken - 18 Oct 2004 19:11 GMT

OK, so it seems that the HeaderFooters collection is contained by the Section
object, but is not contained by the StoryRanges collection. So iterating over
the StoryRanges collection does not hit the header object in my document.

Anyway, there does seem to be a direct object hierarcy from Document to
Fields. So I tried the following.

Dim Status as Integer
Status = ActiveDocument.Fields.Update

which works, but

Dim Status as Integer
Status = ActiveDocument.Fields.Unlink

will not compile, with the message " Expected Function or Variable". I also
get the same compile time error with the ToggleShowCodes method.

Still fogged in,

Ken

> Peter,
>
[quoted text clipped - 80 lines]
> > >
> > > Thanks for your help with this problem.

Reply to this Message

Peter Jamieson - 19 Oct 2004 12:38 GMT

The StoryRange collection structure is pretty weird (in fact, it's weirder
than I'd realised). You need something like:

Sub sad()
Dim oStory As Range
For Each oStory In ActiveDocument.StoryRanges
Debug.Print oStory.StoryType
oStory.Fields.Unlink
While Not (oStory.NextStoryRange Is Nothing)
Set oStory = oStory.NextStoryRange
Debug.Print oStory.StoryType
oStory.Fields.Unlink
Wend
Next

However, that might not be the final word...

> Dim Status as Integer
> Status = ActiveDocument.Fields.Update
[quoted text clipped - 6 lines]
> will not compile, with the message " Expected Function or Variable". I also
> get the same compile time error with the ToggleShowCodes method.

The reason for this is that Update is a "Function" (i.e. with a result) and
Unlink is a "Sub". Although the VBA Help does not (or did not) usually
distinguish explicitly whether a method is one or the other, you will
usually find documentation on any results returned. The Object Browser is
sometimes helpful for this kind of thing too. FWIW Word VBA Help says the
following about the return value of Update:

Field or Fields object: Updates the result of the specified object. When
applied to a Field object, returns True if the field is updated
successfully. When applied to a Fields collection, returns 0 (zero) if no
errors occur when the fields are updated, or returns the index of the first
field that contains an error.

Signature

Peter Jamieson

> OK, so it seems that the HeaderFooters collection is contained by the Section
> object, but is not contained by the StoryRanges collection. So iterating over
[quoted text clipped - 102 lines]
> > > >
> > > > Thanks for your help with this problem.

Reply to this Message

Ken - 19 Oct 2004 17:41 GMT

Peter,

This is the code that does the job for me.

Sub UnlinkAllSections()
Dim oSection As Section
Dim I, intSectionCount As Integer
intSectionCount = ActiveDocument.Sections.Count
For I = 1 To intSectionCount
ActiveDocument.Sections(I).Range.Fields.Unlink
ActiveDocument.Sections(I).Headers.Item
(wdHeaderFooterPrimary).Range.Fields.Unlink

ActiveDocument.Sections(I).Footers.Item(wdHeaderFooterPrimary).Range.Fields.Unlink
Next
End Sub

It just unlinks the section range, then attacks the individual
headers/footers in the section. I wish I knew how to iterate over the
HeaderFooter collection, but couldn't quite get it. Maybe it has something to
dio with collections that have fixed index values predefined as constants.

Anyway this works for me.

Many thanks for your great help.

Ken

> The StoryRange collection structure is pretty weird (in fact, it's weirder
> than I'd realised). You need something like:
[quoted text clipped - 172 lines]
> > > > >
> > > > > Thanks for your help with this problem.

Reply to this Message

Peter Jamieson - 19 Oct 2004 18:31 GMT

OK, thanks for the feedback.

Signature

Peter Jamieson

> Peter,
>
[quoted text clipped - 8 lines]
> ActiveDocument.Sections(I).Headers.Item
> (wdHeaderFooterPrimary).Range.Fields.Unlink

ActiveDocument.Sections(I).Footers.Item(wdHeaderFooterPrimary).Range.Fields.
Unlink

> Next
> End Sub
[quoted text clipped - 186 lines]
> > > > > >
> > > > > > Thanks for your help with this problem.

Reply to this Message