App.activeDocument no longer works right

Question

In a different topic, I was explaining my use of app.documents[0] rather than app.activeDocument. I was going to elaborate some about the differences when I hit a snag. There was a dramatic change after CS3 and apparently nobody noticed. I didn't until today. Look at this simple script that expects there to be more than one document open:
docZero = app.documents[0];
activeDoc = app.activeDocument;
$.writeln("docZero: " + docZero.name);
$.writeln("activeDoc: " + activeDoc.name);
// move back document to front
app.activeDocument = app.documents[-1];
$.writeln("\ndocZero: " + docZero.name);
$.writeln("activeDoc: " + activeDoc.name + "\n");
$.writeln("docZero: "+ docZero.toSpecifier());
$.writeln("activeDoc: " + activeDoc.toSpecifier() + "\n");
In CC, I was astonished to discover that I got this result (after creating two untitled documents):
docZero: Untitled-2
activeDoc: Untitled-2
docZero: Untitled-2
activeDoc: Untitled-2
docZero: /document[0]
activeDoc: /document[@id=2]
That second docZero ought to say Untitled-1. Untitled-1 was definitely moved to the front by the app.activeDocument = app.documents[-1] statement. So looking at the docZero specifier, how come I got the wrong name?
I decided to check my sanity and went back to see what happens in CS3 -- the oldest InDesign I still have installed (actually, on two different computers, so I tried it on both). CS3 gives:
docZero: Untitled-2
activeDoc: Untitled-2
docZero: Untitled-1
activeDoc: Untitled-2
docZero: /document[0]
activeDoc: /document[@name="Untitled-2"]
There's two interesting things here:
The second docZero message has the correct name of the document that was moved to the front.
In those days, documents were identified by name, not id.
Point 2 is interesting but off topic.
So I tried CS4 (also on two machines). It gave:
docZero: Untitled-2
activeDoc: Untitled-2
docZero: Untitled-2
activeDoc: Untitled-2
docZero: /document[0]
activeDoc: /document[@name="Untitled-2"]
So this is when things started to go wrong. Interestingly, documents were still identified by name in CS4, so it wasn't that change that caused the change in behavior. It was CS5 (which produced exactly the same output as CC) where the specifier changed to using the id -- a property that had not previously existed for Document objects.
So, I guess the question is: Is this a bug? Looks like one to me. Looks like it stopped working after CS3.
Dave
Message was edited by: DaveSofTypefi -- minor formatting change

Answer 1

Hi Dave,
This is a typical specifier resolution problem, and indeed this is not related to id-based document specifiers introduced in CS5.
How specifiers are resolved is consistant since CS4—except for Text and Cell specifiers, but this another story.
Here is what happens:
Unlike activeDoc = app.activeDocument (which is instantly resolved), docZero = app.documents[0] remains an unresolved specifier until you hit some property on it, which is done at the next line, when you innocently display the name property:
$.writeln("docZero: " + docZero.name); // this code sends a command that resolves docZero
Then, whatever you do, docZero is internally resolved to an actual receiver (the Untitled2 document), even if the specifier string accessed from docZero.toSpecifier() still contains the original path "/document[0]". Ironically, if you didn't prompt docZero.name before sending the command app.activeDocument = app.documents[-1]; then docZero would have been properly resolved to the Untitled1 document! Remove the first $.writeln and you will see the change.
Now, the question is: how to force a new resolution of the specifier considering its formal path "/document[0]". The answer is getElements(). Just access this method and the magic happens:
docZero = app.documents[0];
alert("docZero: " + docZero.name);          // => Untitled-2
// move back document to front
app.activeDocument = app.documents[-1];
docZero.getElements();                      // resolve again!
alert("\ndocZero: " + docZero.name);        //  => Untitled1
alert("docZero: "+ docZero.toSpecifier());  // still /document[0]
See also: http://www.indiscripts.com/post/2010/07/on-everyitem-part-2
@+
Marc