(JS) Find Page of Object

Question

While preparing a presentation I'm going to be giving in a couple of months, I took a good hard look at my findPage(theObj) function and I think that this is as good as it gets:
function findPage(theObj) {
  if (theObj.hasOwnProperty("baseline")) {
    theObj = theObj.parentTextFrames[0];
while (theObj != null && theObj.constructor != Page) {
    var whatIsIt = theObj.constructor;
    switch (whatIsIt) {
      case null : return null;
      case Character : theObj = theObj.parentTextFrames[0]; break;
      case Cell : theObj = theObj.insertionPoints[0].parentTextFrames[0]; break;
      case Application : return null;
    if (theObj == null) return null;
    theObj = theObj.parent;
  return theObj
} // end findPage
The previous versions posted in various threads here reflected various degrees of needless caution about what might happen, for example if the object were anchored to text in a cell in an overset table. The above returns null in that case with no need for try/catch.
Notice the use of objects rather than their names. Works! This is similar to the instanceof construction but it's easier to test the negative.
If anyone can knock a hole in the above script, I'd be very interested in hearing about it.
Dave

Answer 1

[email protected] wrote:
> Thanks Harbs, interesting points.
>
> 1. I've resisted the use of while(theObj) because it just feels unnatural from a readability point of view. It might be worth setting up a timing test to compare the speed of it with while(theObj != null).
>
>
I find (theObj) more readable, but that's probably because I have a
funny way of thinking, and don't like reading anything extra... ;)
I remember the first time I saw Kris use "0" instead of false and "1"
instead of true, it looked so odd to me, but I've gotten so used to the
short-hand way of writing everything that the long-hand way looks clumsy!
My point here was that "theObj.constructor != Page" was not necessary.
> Your idea of moving the catch for Page into the switch is interesting. That would actually make it impossible to drop out the bottom of the while loop.
>
>
Exactly. Here's (approximately) what I meant: (It should work in CS3 and
later -- in CS2 and earlier, storyOffset was a number and not a
character) Also, Notes can have a lot of nesting, and this will not
catch that...
function FindWhere(theObj,where) {
var err;
if(where==undefined){where=Page}
if (theObj.hasOwnProperty("baseline")) {
try{theObj = theObj.parentTextFrames[0];}
catch(err){}
while (theObj != undefined) {
var whatIsIt = theObj.constructor;
switch (whatIsIt) {
case where : return theObj;
case Note:
case Footnote: theObj = theObj.storyOffset;break;
case Character : theObj = theObj.parentTextFrames[0]; break;
case Cell : theObj =
theObj.insertionPoints[0].parentTextFrames[0]; break;
case Application : return null;
if (theObj == undefined) return null;
theObj = theObj.parent;
return null;
> 2. A test for null catches undefined values. I've always used that test, so I'm going to stay with it. Again, the form if(!theObj) strikes me as something I'd have to pause and think about for a moment each time I read it, so I tend not to use that construction.
>
>
Yes, I know "==null" works. My point was that if you want the
readability factor, "==undefined" is more correct -- the text frame is
undefined and not null. To illustrate this point theObj === undefined
will return true, while theObj===null returns false.
> 3 & 4. Aha, I never thought about footnote references and notes. They hardly ever come up in my scripts so I hadn't had the need to think about them.
>
> 5. "infinitely"?
>
>
Okay. "Infinitely" might be a bit of an exaggeration, but I do use
"FindWhere" on a lot of different levels. For example, it's very useful
for finding if an object is on a MasterSpread.
> At one point, my version of this function did indeed return the last text frame of a story if the object were in overset text, but I ended up realizing that this was rarely useful and indeed misleading. But it is an option that is occasionally needed.
>
>
I find it very useful indeed. I have a separate function to verify
oversets if necessary.
> Thanks for the feedback.
>
> Dave
>
Harbs
http://www.in-tools.com