StoryRanges collection

[Chad DeMeyer]

I have seen numerous posts on the functional method for updating all fields
in a document:

Dim oRange As Range
For Each oRange In ActiveDocument.StoryRanges
Do
oRange.Fields.Update
Set oRange = oRange.NextStoryRange
Loop Until oRange Is Nothing
Next

What I haven't seen is an explanation of why this method is necessary. Is
there something wrong with the StoryRanges collection? Normally, a For Each
construct would suffice to loop through the members of a collection, so why
with StoryRanges is it necessary to also loop through the collection using
the NextStoryRange method until its return is Nothing? Furthermore, it
seems like the code above should update the fields in each StoryRange
multiple times, the number of times being equal to the number of StoryRanges
in the document.

Hoping somebody can fill in the blanks.
Regards,
Chad

 

[Doug Robbins]

Hi Chad,

I think that we explain it in the article "Using a macro to replace text
where ever it appears in a document
including Headers, Footers, Textboxes, etc." at:

http://word.mvps.org/FAQs/Customization/ReplaceAnywhere.htm


--
Please respond to the Newsgroup for the benefit of others who may be
interested. Questions sent directly to me will only be answered on a paid
consulting basis.

Hope this helps,
Doug Robbins - Word MVP

 

[Chad DeMeyer]

Thanks, Doug
I now understand what it is working around, but I'm forced to conclude that
there IS a problem with the StoryRanges collection - each member returns a
single contiguous range even though multiple non-contiguous ranges may be
contained within the StoryRange. So we work around that by...returning the
non-contiguous ranges with the same property (.StoryRanges)? This is, IMHO,
a major weakness in the Word object model. They should have defined a
separate collection of the different ranges within a story, something like
StorySubRanges, then it would have been clearer and more intuitive to access
each range in the document.

Regards,
Chad

 

[Jezebel]

It seems to me it was a design compromise. In one sense you're right: it
would be more intuitive if StoryRanges were a collection of collections. On
the other hand, the StoryRanges that may contain more than one range take
the form of explicitly linked lists for some types of processing. This
linking is more than just the sequence of the ranges within the document --
headers with the 'link to previous' setting, for example. Within the classic
object model, a member of a collection has no direct knowledge of its
siblings, so building this requirement into this particular collection would
have entailed an amount of 'special case' programming that the designers
apparently preferred to avoid.

 

[Peter Hewett]

Hi "Chad DeMeyer" <cjdemeye at bechtel dot com>

StoryRanges are inherently contiguous, it's just that what we think of as a Word document
is not. When you break your Document up into multiple Sections, each with vastly
different attributes in makes no real sense in trying to represent these as a single
Range. It's not particularly intuitive, but is more usable (in that it's more granular)
than a SuperSet StoryRange that applies every StoryRange of a given type or even the
entire document!

Cheers - Peter

Thanks, Doug
I now understand what it is working around, but I'm forced to conclude that
there IS a problem with the StoryRanges collection - each member returns a
single contiguous range even though multiple non-contiguous ranges may be
contained within the StoryRange. So we work around that by...returning the
non-contiguous ranges with the same property (.StoryRanges)? This is, IMHO,
a major weakness in the Word object model. They should have defined a
separate collection of the different ranges within a story, something like
StorySubRanges, then it would have been clearer and more intuitive to access
each range in the document.

Regards,
Chad

HTH + Cheers - Peter

 

[Jay Freedman]

Hi Chad,

You've hit one of the perennial sore spots -- feels like an abscessed
tooth by now. :-(

There are a fair number of things in the object model that range from
inconvenient through illogical to incomprehensible (not to mention the
things that simply aren't implemented). The sticky part is that many
of these things have become "standard" -- if MS fixed them, tons of
existing VBA code would break. I don't like it, but I can see their
point.

We've repeatedly requested that Find/Replace and Update Fields, when
invoked on ActiveDocument.Range, should affect all parts of the
document. It hasn't happened yet...

 

[Birgit]

Hi all,

"Jay Freedman" schreef :

We've repeatedly requested that Find/Replace and Update Fields, when
invoked on ActiveDocument.Range, should affect all parts of the
document. It hasn't happened yet...

I ran into this same problem and because I was not aware of the code Chad
posted (see below), I tried circling through the headers and footers by way
of a counter. That took too long, and I could not access a field inside a
table inside a textbox inside a header (on page 2, section 2), so I came up
with the solution of switching to pagepreview and back to the original view.
It's dead fast and it worked (I believe I tested it even with the
print-option update fields turned of - or possibly I temporarilty turned the
option on, don't remember).

Am I creating problems for myself?
Birgit


----quote follows----
Dim oRange As Range
For Each oRange In ActiveDocument.StoryRanges
Do
oRange.Fields.Update
Set oRange = oRange.NextStoryRange
Loop Until oRange Is Nothing
Next

 

[Jay Freedman]

Hi Birgit,

There is a slight problem: the print preview method doesn't update a table
of contents or any fields that refer to document properties, such as
{author}. See this thread for another solution:

http://groups.google.com/[email protected]

 

[Birgit]

Hi Jay,
thank you for your comment. I will keep it in mind for future reference.
Currently I am not using TOC or the standard document-properties. I have not
run into a problem with custom document properties so far. This might be,
however, because my customer is still using Office 97.

Birgit

 

[Jay Freedman]

Hi Chuck,

Sadly, that line does update only fields in the main body. It doesn't touch
headers, footers, text boxes, etc.

 

[Chad DeMeyer]

Thank you to Doug, Jezebel, Peter, and Jay for your thoughts on this topic.
I think I understand Jezebel's and Peter's points, but I still believe that
this part of the Word object model could have and should have been
constructed differently. How much time and frustration was spent by the
programmer(s) who developed the For Each with nested Do Loop kludge? :>}

Regards,
Chad