1 person found this helpful
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:
activeDoc = app.activeDocument(which is instantly resolved),
docZero = app.documentsremains 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".Ironically, if you didn't prompt
docZero.namebefore 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". The answer is getElements(). Just access this method and the magic happens:
docZero = app.documents; 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
That explains what I'm seeing. I'm not sure this is a step forward from CS3, and the fact that it's taken me six years to notice suggests that in the big scheme of things it's not very important -- although understanding the underlying principles is.