1 person found this helpful
(Hm. Perhaps a little more on that.)
"Pages" don't have a pointer to Text, just to its text frames. But that's all you need -- from a text frame you can access its paragraphs immediately.
There are a few caveat imptor's associated with this! The first paragraph may actually start on the previous page, for example (just like the last paragraph may run into another text frame on another page).
If your document is a simple one-textframe-per-page story, threaded and all, you could use the first text frame on your page that has a nextTextFrame as a starting point, then use nextTextFrame to process each frame (rather than page), until there is no next frame anymore. It depends on why you'd want to do this Tables and figures and call-out boxes in frames of their own won't get processed, and neither will pages that don't appear in this threaded story.
Yes, I thought of the paragraphs starting on the previous page and/or ending on the next. I was really hoping that the paragraphs had a unique id like page items but alas. If that were the case then I'd just keep a list of the ids as I came across them and check to make sure each paragraph's id wasn't already in the list.
This is a script that was working only on the story the in which the cursor was planted. I'm attempting this upgrade because I'm taking a bear of a series and trying to eliminate some of the 300+ styles that are in the InD file. Unfortunately, on these pages there can be as many as 5 different text frames with different stories, sometimes flowing through other frames, sometimes not. So, processing by page is really the only logical way.
Ah ha! Maybe I can keep track of the ParentStoryID along with the paragraph's index to avoid processing the same paragraph twice on two different pages! Hmm, I'll look into that!
Any other ideas are welcome.
Thanks for responding!
OK so it looks like this might work. But riddle me this: Why does it appear that this:
appears to be returning the Index of the first CHARACTER in the paragraph? Is that just the way it works? Any ideas why?
Oy! Ever onward!
1 person found this helpful
Yes, that's how it works. All Text related indexes are the index of the first insertion point of that text object. It's NOT the index within its collection.
In case anyone is interested I decided to create a collection of texts, I'm working in VB with a recursive routine to which you pass a text object.
I'm going page by page interating through all the text frames on a page passing their text objects to the routine. The routine iterates through all the anchored frames and table cells in that text object passing all THOSE text objects to itself. Each time the routine is called it adds to the texts collection. When done I can process all the elements of the texts collection looking at the paragraphs to do what I need.
I started to use an array but I wasn't able to find an accurate way to determine just how many text boxes were in the file to dimension the array. Wat's interesting is that ActiveDocument.TextFrames.Count returns the correct number of frames counting one level deep of anchored frames (a frame anchored in the first text frame on the page). But, anchor a frame within an anchored frame and that 2nd anchored frame wasn't included in the count.
Thanks for the everyone!!