Current items, page or text frame

[Guest]

Is it me or is it silly that .ActivePage isn't the page one is actually working on?

Anyway, I'm trying to get the current page number and have seen posts suggesting using the geometric bounds of the current item (in this case a text box) but I've not found a way to simply get the current text box. I'm surprised there is no simple command of .CurrentTextFrame or something of the like.

What is the easiest way to find the text box my cursor it in?

Thanks for the help,
Ken

[_Robert_Tkaczyk_]

in VB:

myInDesign.Selection.Item(1)
myInDesign.Selection.Item(2)
myInDesign.Selection.Item(3)
...

myInDesign.ActiveWindow.ActiveSpread

myInDesign.ActiveWindow.ActivePage

and you can look at different page than your selection is - you can scroll from current page/spread to different page/spread

robin

--
www.adobescripts.com

[Guest]

I actually found that shortly after I posted my message.

But I've not been able to find how to get the text frame when the cursor is planted in the text. Any idea?

Thanks a bunch for the time!
Ken

[Peter Kahrel]

>how to get the text frame when the cursor is planted in the text.

myInDesign.Selection.Item(1).ParentTextFrames.Item(1)

Peter

[Guest]

The Parent item will be very handy.

Thanks a million Peter.

Ken

[Peter Kahrel]

"Parent" is an important language element. There are general parents: a text frame's parent is the page the frame is on; an insertion point's parent outside a table is its containing Story; an insertion point's parent in a table is the cell it's in; a cell's parent is the table the cell is in. There are also grandparents: in a table,
>myInDesign.Selection.Item(1).Parent.Parent

is the table. There are also some special parents: ParentTextFrames[0], ParentStory, ParentRow, and ParentColumn. It's worth your while to experiment with the notion 'parent'.

Peter

[_Dave_Saunders_]

I just wrote a script that involved groups of text frames and a linked graphic. To get at the group from the link, I needed:

myLink.parent.parent.parent

The first parent is the graphic, the next is its frame, and the next is the group.

Also, bear in mind that groups and anchored objects can interfere with the natural scheme of parentage. Those groups happened to be inline to a story, so each of them had as parent a character (in the story).

For text objects, be sure to differentiate between parent and parentStory. Outside of a table, the parent of a text object is the same as the parentStory. But, inside a table, the parent (as Peter says) is the cell while the parentStory is the story holding the table (and if the tables are nested, it's the story holding the top-level table.

Perhaps we should co-author a book on parenting, Peter, what do you think? ;-)

Dave

[_Dave_Saunders_]

There's a further complication in the CS3 object model. The description of the parent property (in ESTK's Object Model Viewer) confuses the actual parent for what I call "owners".

For example, the parent property of a page is described like this:

Page.parent (Read Only)
Data Type: any
The parent of the Page (a Spread, MasterSpread or Document).

But in fact, while a Document object owns a pages collection, the parent of a page can only be a Spread or MasterSpread object.

Another example. The parent property of a pageItem has this description:

PageItem.parent (Read Only)
Data Type: any
The parent of the PageItem (a XMLElement, XmlStory, Spread, MasterSpread, PageItem, Oval, Rectangle, Polygon, GraphicLine, Group, State, TextFrame, Story, Text, Character, Word, Line, TextColumn, Paragraph, TextStyleRange, Cell, Table, Document, Layer, Page, Button, InsertionPoint or Footnote).

Differentiating which is which among this lot is more challenging. I believe that of this list, only these are actually possible parents:

Spread -- for page items that are on the pasteboard of a document spread.

MasterSpread -- for page items that are on the pasteboard of a master spread.

Oval, Rectangle, Polygon, GraphicLine, Group, Button -- for page items that are pasted inside any of these. Note that PageItem objects are generic and so they can own other page items, but they'll never be returned to your script as a parent; you'll always get the specific kind of page item.

Character -- for page items that are inline or anchored to a story. All the other Text objects can own page items -- that is, they can have within them inline or anchored page item collections, but the parent is always the character that holds the actual object in question. [Special note about InsertionPoints: it always has an empty collection of PageItems; once you populate that insertion point with a page item, it becomes (or spawns, depending on how you look at it) a character. Note that because PageItem is a generic kind of object, you can't use add() on a collection of page items -- you have to add a specific kind of page item.]

I think that's it. All the rest can own collections of page items, but they will never be returned if you access the parent property.

Special note concerning the TextFrame object: in CS and CS2, the text frame collection of a story returned the text frames (and text paths) that constituted the story. In CS3, you get the text frames/paths that are anchored to the story. In any of these releases, the parentStory of a text frame is the story contained within the the frames/paths. This means that in CS3:

myStory.textFrames.parentStory

returns the story contained within the nth text frame anchored inside myStory while in CS2 and CS3 it gives you back myStory because of the different meaning of textFrames.

Another interesting inconsistency. Notice that while text frames and text paths are both text containers, a text path does not have a page items collection. To get at that, you need to use:

myTextPath.texts[0].pageItems;

Hence, TextPath is not included in the list of "parents" of a page item in the OMV.

Dave

[Peter Kahrel]

If you're typing away in a table that's in an inline frame and you want to insert at the insertion point the version and build of your copy of InDesign, this

>app.selection[0].contents = app.selection[0].parent.parent.parent.parent.parentTextFrames[0].parent.parent.parent.parent.version

would do that. Ugh! Can you imagine what would happen if you're in a table in an inline in a cell? A book on parenting is definitely needed!

Peter

[_Dave_Saunders_]

True, but methinks that code is rather fragile!

Dave

[_Darwin_Campa_]

I came up with this for finding page numbers of links:

> var thisObj = myLink;
var myPageLocator = false;
while( myPageLocator == false ) {
try {
thisObj.parent.showMasterItems; // throws an error if the parent isnt a spread or masterspread (the only 2 objects that support showMasterItems)
var myObjPageNum = thisObj.name;
myPageLocator = true;
} catch(err) {
var thisObj = thisObj.parent;
}
}

A little convoluted, but i'm a noob, and hey, it works for me. :D

[Harbs.]

Using try/catch has a bit of overhead. This does pretty much the same
thing, but it's more efficient.

var thisObj = myLink;
var myPageLocator = false;
while( myPageLocator == false ) {
if(thisObj.parent instanceof Spread || thisObj.parent instanceof
MasterSpread){
var myObjPageNum = thisObj.name;
myPageLocator = true;
}
else{var thisObj = thisObj.parent;}
}

Harbs

[Peter Kahrel]

What about
>myLink.parent.parent.parent.name

Peter

[_Darwin_Campa_]

Peter: the problem with that is that it's possible to have image links at varied levels in the document hierarchy. 😕 So while that would work for most images, don't forget that pages/spreads have the document as a parent.

Also, it's possible to embed a link in a text frame within a table cell that is in another text frame, etc, so there's no way of really knowing how many parents you need to traverse without looping and checking.

Of course, I could be wrong. :D

[Peter Kahrel]

Darwin,

True -- I forgot about deeply embedded items.

Peter

[_Darwin_Campa_]

Nice, Harbs. I didn't know about the instanceof thing, or I probably would have arrived at something similar. That definitely seems to be the cleanest way to go about things. Of course, the next JSX will probably have a WHAT_FREAKING_PAGE_IS_THIS_ON property, and make all of this pointless. :)