🚀 go-pugleaf

I think I've already knocked a hole in it -- nothing like exposing stuff to public view for finding problems! With the test in the while statement for null, the null case is not possible in the switch.

Indeed, the only time that null test at the top of the loop kicks in is if the original object is overset text because of the test for null after the switch -- necessary because null doesn't have a parent.

Dave

Hi Dave,

Objects on the pasteboard return Spread--or, at least, they used to. If your intent was to have this handled by Application, then never mind.:-)

Thanks,

Ole

Ole,

For this script, yes. If an object is on the pasteboard then it's not on a page.

Dave

I think I see why I used to include the case of Story (which returned null). If the object is a table that is overset, then its parent is the story. That winds its way up through Document and Application to get to the correct null result, so I think I'll leave it like that.

Dave

> If anyone can knock a hole in the above script, I'd be very interested in hearing about it.
>   

What a fun  challenge! ;)

Besides the unnecessary case (which you mentioned already):

1) AFAIK, every object has a valid parent, even the app itself has
itself as a parent -- itself. There's no way to get through the loop a
second time with "null".

I would do a while(theObj) without any conditions because once you made
it in, you can't get out without either returning null or getting your
page. I'd just add a case of Page and return theObj and at the end of
the function return null

2) Also, "if (theObj == null)" is probably not technically correct. "if
(theObj == undefined)" is more accurate (since the only way to get there
is with an undefined text frame). (Although I'd just use if(!theObj) for
the sake of brevity...)

3) It does not deal with references to Footnotes (although it will work 
if given a reference to the text inside a footnote).

4) Your function does not deal with notes. It will not find the page a 
note is on, and will error if given a reference to text inside a note.

5) You can make the function infinitely more useful by adding a second
argument which could accept any InDesign object which can contain
objects (like Spread, MasterSpread, TextFrame, etc.) I usually want to
find the location of the last text frame on overset text, so I prefer to
use (a variation of) jxswm's version of the function (which finds the
last text frame).


-- 
Harbs
http://www.in-tools.com

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).

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.

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.

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"?

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.

Thanks for the feedback.

Dave

Dave_Saunders@adobeforums.com 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