Reference to textFrame changes when changing geometricBounds

[SimonLinden]

Hi,

I'm not sure if anyone can help me with this issue but I'm throwing it out here and hoping for the best. I'm having a strange behavior in a script I'm running. It's quite an extensive script (about 1000 lines) so it may be more confusing if I try to provide too much information. But the heart of the issue is that I have many pages with several text frames on each. For the first page I have variables pointing to the first text frame in each separate story, crossRefTextFrame is one and footnotesTextFrame is another. Then, in another function I'm looping through all text frames on all pages and moving them around by changing their geometricBounds.

It is when I change the size of the the cross ref text frame by changing its geometicBounds that the variable crossRefTextFrame also starts pointing to the footnote text frame instead. However this doesn't happen if I add a line to select the cross reference text frame just before changing the geometricBounds.

The code below is where crossRefTextFrame starts pointing to another text frame. I have two variables pointing to the same object; frame is a local variable only used in this function and crossRefTextFrame is available throughout the script:

frame.geometricBounds = [gilbrantTop, leftMargin, gilbrantBottom, rightMargin];
crossRefTextFrame.select();
exit();
//the footnotes text frame is now selected

But if I add a seemingly irrelevant command before changing the geometricBounds things work as they should (crossRefTextFrame is still pointing to the same frame)

crossRefTextFrame.select();
frame.geometricBounds = [gilbrantTop, leftMargin, gilbrantBottom, rightMargin];
crossRefTextFrame.select();
exit();
//the cross references text frame is now selected like it should be

I don't expect anyone to be able to pinpoint the exact reason as that may require a deep look into my script. But perhaps some advice? Is changing geometricBounds known to cause problems? Or can having to variables pointing to the same object have undesired consequences?

Right now my script seems to work fine because I'm using the second script above. But it just seems like I have a more serious error deeper down in the code which I'm just avoiding in an unorthodox manner.

[Marc Autret · Accepted solution]

Hi Simon,

I'm afraid we can't help without additional clues. At least we'd need detail on how your variables frame and crossRefTextFrame are defined upstream.

But—agnostically—it's a safe bet that you're dealing with the internationally known “Unresolved Specifier Issue.” That is, your crossRefTextFrame reference is probably not resolved (yet) at the moment you change frame's geometric bounds. Then, hitting the frame specifier causes, for some reason, a collateral effect on the actual receiver of the other variable.

How is it possible? Let's take an example to illustrate this point. Suppose you have this initial setup:

Simple, right? A single-page document, three text frames stacked as shown in the Layers panel, HEAD and FOOT being already positioned in the page while EXTRA stands outside of it, in the spread area. So the following declarations faithfully reflect the initial configuration:

var doc = app.activeDocument,
    pageFrames = doc.pages[0].textFrames,
    // ---
    head = pageFrames[0],
    foot = pageFrames[1],
    // ---
    extra = doc.textFrames.itemByName('EXTRA');
// Let's go dancing...

Then, suppose we reposition EXTRA as follows (before selecting foot😞

// Let's go dancing...
extra.geometricBounds = [100,-100,150,20];
foot.select(); // Did you guess which block is actually selected?

And the winner is . . .

Why does foot.select() cause EXTRA to be finally selected?!? Because EXTRA now belongs to the page (due to geometricBounds reset), and the foot specifier hasn't been resolved before our move. Syntactically, foot still refers to pageFrames[1] (as originally declared) which now points out to EXTRA (while FOOT has now index 2, with respect to layer ordering.)

Specifiers are resolved only when you hit them through a DOM command, such as select().

Suppose we used this code instead:

// Let's go dancing...
foot.select(); // => FOOT is selected (and now *resolved*.)
extra.geometricBounds = [100,-100,150,20];
foot.select(); // => FOOT remains selected.

The mere fact of resolving foot before moving extra into the page magically changes the outcome:

As you can see, this very basic example exhibits a 'bug' which is quite similar to the issue you observe in your script. So, you're likely in a case where crossRefTextFrame should be forced to resolve before further processing—using tricks like getElements() and so on. Of course many other factors may be involved in a “Unresolved Specifier Issue,” but that's the big picture.

@+

Marc

[SimonLinden]

A very big THANK YOU for taking the time to give me such a detailed explanation on this issue. Just like you suggested the crossRefTextFrame has not been resolved at this point in the code. I had no idea it was important, but because of your example I can understand why. My textframe variables (crossRefTextFrame, footnotesTextFrame etc) are declared by identifying their applied object styles, and as a part of the script I actually change the object style of  the crossRefTextFrame. So perhaps that is what confuses the pointer.

[Loic.Aigon]

And you say you don't feel like training people