Skip to main content
vze26m98
Known Participant
May 29, 2011
Answered

ExtendScript: Reading vs. writing InDesign references

  • May 29, 2011
  • 1 reply
  • 711 views

Hi all-

Not hugely versed in Javascript as well as InDesign, so perhaps this is a language rather than application question. I have some code that looks like this:

var theSelection = app.documents.firstItem().selection;

var theTextFrames = theSelection[0].parentStory.texts;

var numTextFramesSelected = theSelection.length;

var documentFilePath = app.activeDocument.filePath;

function ROW(i){

  return theTextFrames.item(0).associatedXMLElements;

}

function DATA(i, COL){

  return ROW(i)[COL].xmlElements.item(0).contents;

}

function setDATA(i, COL, boxContents){

  ROW(i).item(COL).xmlElements.item(0).contents = boxContents;

}

So, the notion is that the element references that are used in the functions are built from variables that contain portions of the element reference. The portions of the code that READ the elements seems to work OK, but the portions that WRITE to the elements inevitably fail. Any thoughts on what I'm doing wrong here?

A further question: I know I can refer to my InDesign elements like so:

app.documents.firstItem().selection[0].parentStory.texts[0].associatedXMLElements

but my past association with Applescript always encouraged me to get my references as few times as possible, I guess because of the cost of inter-application communication in Applescript's case.

But with ExtendScript, is there a performance penalty in getting these references each time you run through a loop?

Thanks, Charles

This topic has been closed for replies.
Correct answer John Hawkinson

Hello.

"Inevitably fail" is awful vague. Just what happens that goes wrong?

app.documents[0] is a lot more compact than .firstItem(), btw.

A further question: I know I can refer to my InDesign elements like so:

app.documents.firstItem().selection[0].parentStory.texts[0].associated XMLElements

but my past association with Applescript always encouraged me to get my references as few times as possible, I guess because of the cost of inter-application communication in Applescript's case.

But with ExtendScript, is there a performance penalty in getting these references each time you run through a loop?

Yes there is. But I wouldn't worry about it unless you were doing 100s of iterations rather than 10s. But one can use

var myArray = ....associatedXMLElements.everyItem().getElements();

and then loop for (i=0; i< myArray.length; i++)

1 reply

John Hawkinson
John HawkinsonCorrect answer
Inspiring
May 29, 2011

Hello.

"Inevitably fail" is awful vague. Just what happens that goes wrong?

app.documents[0] is a lot more compact than .firstItem(), btw.

A further question: I know I can refer to my InDesign elements like so:

app.documents.firstItem().selection[0].parentStory.texts[0].associated XMLElements

but my past association with Applescript always encouraged me to get my references as few times as possible, I guess because of the cost of inter-application communication in Applescript's case.

But with ExtendScript, is there a performance penalty in getting these references each time you run through a loop?

Yes there is. But I wouldn't worry about it unless you were doing 100s of iterations rather than 10s. But one can use

var myArray = ....associatedXMLElements.everyItem().getElements();

and then loop for (i=0; i< myArray.length; i++)

vze26m98
vze26m98Author
Known Participant
May 29, 2011

[The cleanup mentioned below, plus correcting an incorrect parameter value >blush< fixed my issue. Thanks again!]

Hi-

Thanks for your interest.

Re: the efficiency of iterations, I could possibly have a thousand, but I have to believe it will go faster than Applescript. The pointer to getElements() is very helpful.

As far as my main question goes, here's some cleaned up code. (Between a review of what I had and your suggestions, it's much simplified:)

function DATA(i, COL){

  return app.documents[0].selection.associatedXMLElement.xmlElements[COL].contents;

}

function setDATA(i, COL, boxContents){

  app.documents[0].selection.associatedXMLElement.xmlElements[COL].contents = boxContents;

}

When I run this, I'm able to READ the DATA through the first function, but WRITING the DATA through the second function gives me this:

So perhaps the typeof "contents" is an object and not a string, so ExtendScript does the conversion on read, but not on write?

Anyway, any insight is greatly appreciated!

Best, Charles

Message was edited by: vze26m98