Scripting FAQ as Wiki

[_Dave_Saunders_]

Mark Niemann-Ross of Adobe has generously allowed us to use the scripting section of his developers' wiki as a scripting FAQ. So, I've seeded a few pages (in the JavaScript section, of course) but wikis are communal efforts, so everyone is invited. But please don't use the wiki pages to ask questions; that's what these forums are for.

The discussion pages on the wiki can be used to asked for clarification of a page, but even then, you'll probably get a faster response and a bigger audience by asking here.

The FAQ address is listed in the Useful Resources space of the forum main page, as well as here:

http://www.niemannross.com/developer/wiki/index.php?title=InDesign_Scripting

To contribute to the FAQ (as opposed to just reading its contents), you'll need an OpenID. Took me a while to work out how to do that. What I did was go to:

http://getopenid.com/

and create an account. If you want more background information, click the 'What is OpenID' link on the left panel of the wiki.

I look forward to seeing people at the wiki and hope the content proves to be useful to everybody.

[_G__Bilalis_]

I will be traveling on business beginning Saturday the 13th of October and will have limited access to my email. I will be back in the office on Monday the 22nd of October. For emergencies please contact sales@anodos.gr, or call mob: +30 6977 215264.

Thank you.

[_Dave_Saunders_]

I've just added a correction to this page:

http://www.niemannross.com/developer/wiki/index.php?title=InDesign_JS_Object_Model_Collections

Just because an object has a label property, and contrary to what the OMV says, it does not necessarily support itemByName(). So far, I've identified pageReferences and crossReferences as belonging to this camp. I'm sure there's more.

Dave

[Harbs.]

I can't get stories to work either.

[_G__Bilalis_]

I will be traveling on business beginning Saturday the 13th of October and will have limited access to my email. I will be back in the office on Monday the 22nd of October. For emergencies please contact sales@anodos.gr, or call mob: +30 6977 215264.

Thank you.

[_Dave_Saunders_]

Feel free to open an account and contribute to the FAQ.

I'll add stories. I was thinking as I walked back from lunch at my daughter's house that stories was another example.

Dave

[Harbs.]

Dave_Saunders@forum.adobe.com wrote:
> Feel free to open an account and contribute to the FAQ.
>
>
I'll try to do that. I've never participated in a wiki before, but
there's a first for everything! :)

Thanks for the great work!

Harbs

[sstanleyau]

On 15/10/07 1:13 AM, "Dave Saunders" <member@adobeforums.com> wrote:<br /><br />> I'm sure there's more.<br /><br />If it mirrors the AppleScript situation, the only classes that support it<br />are page items and its various subclasses (at least, I'm pretty sure that's<br />what Ole said on the matter).<br /><br />-- <br />Shane Stanley <sstanley@myriad-com.com.au><br />AppleScript Pro Florida, Feb 2008 <a href=http://scriptingmatters.com/aspro>

[_Dave_Saunders_]

Thanks for the input. I think it's a bit broader than that. For example, Library Assets support itemByName. I don't have the energy to do a comprehensive evaluation. I guess I'll just add objects to the unsupported list as I discover them. Anyone else is welcome to do the same.

Dave

[_Dave_Saunders_]

At some point in the night, I realized that library assets have names, so they're not part of the issue at hand. It could indeed be that itemByName is only available for nameless, labeled items whose label can be seen in the Script Label panel.

Dave

[_G__Bilalis_]

I will be traveling on business beginning Saturday the 13th of October and will have limited access to my email. I will be back in the office on Monday the 22nd of October. For emergencies please contact sales@anodos.gr, or call mob: +30 6977 215264.

Thank you.

[_Dave_Saunders_]

This (combined with an appropriate selection holding an image labeled "Test") works:

myImage = app.selection[0].images.item("Test");
myImage.itemLink.name

And this fits my suggested rule that if the label can be seen in the Script Label panel it works. Aha, but table labels can be seen there. Let's try it with tables ...

Aha! This worked:

myStory = app.selection[0].parentStory;
myTable = myStory.tables.item("Test");
myTable.bodyRowCount

Now let me try it with more than one table in the story...

Added a three-row, unlabeled table before my "Test" table and it still worked. So now let's see what happens if I have two tables in the story both labeled "Test" ...

Golly! It worked. The script returned:

3,4

Dave

[_Dave_Saunders_]

As a PS: this doesn't extend to cells of a table because cells also have names so itemByName works on the names, not the labels, even though the labels are visible in the panel.

Dave

[_Olav_Kvern_]

Fellow Scripters,

Here's how it works:

* If the object has a name property, ItemByName("myName") will return the item(s) named "myName".

* If the object is a page item (page item, rectangle, oval, graphic line, group, button, polygon, text frame), then ItemByName("myLabel") will return the item(s) with the label "myLabel".

* In all other cases, you cannot trust ItemByName to get an item by the contents of its label. In some cases, it will appear to work (XML elements), but don't be fooled.

Thanks,

Ole (back from sabbatical)

[_Dave_Saunders_]

Sorry, Ole but your description is not completely accurate.

ItemByName only returns a single item when the members of the collection have a name even if there are multiple objects in the collection with the same name.

As I demonstrated this morning, it works for labeled Tables.

While it also appears to work for labeled graphics, I'm not sure that it is actually possible to create a collection of graphics of length greater than one, so it's a bit academic that it works.

And xmlElements have neither a name or a label, so what it's doing there is even more mysterious. I agree with your advice to assume that it doesn't work reliably.

That's why I think a Wiki is a good place to keep this kind of information.

Dave

[_Olav_Kvern_]

Hi Dave,

As far as I know, the content of a name property in a collection has to be unique. Where have you found otherwise?

I would not trust the result from ItemByName for the label property for anything other than page items. If you feel you can, go ahead, but don't say I didn't warn you.:-)

(For XML elements, many people have assumed that the name of the markup tag is the name/label of the element. It even appears to work, some of the time.)

Thanks,

Ole

[_Dave_Saunders_]

Documents, Books, Libraries, Assets, Topics

Dave

[_Dave_Saunders_]

app.activeDocument has a bug in it you can drive a bus through if you're working with two documents open with the same name. It gives you the most recently opened, not the one at front.

app.documents[0].getElements()[0] is functionally equivalent to app.activeDocument and it too has the same problem when two documents are open with the same name.

Dave

[_Dave_Saunders_]

The situation with Topics is interesting. A Topic is formed for each combination of name and sort order, so if you have the "same" topic under more than one sort order, you get a topic object for each combination.

Dave

[_Olav_Kvern_]

Hi Dave,

Ah, yes--I guess I was thinking about named items inside a document (or other, similar container). Actually, I'd call having multiple topics with the same name a bug. The other ones are all what I'd expect--you need to use more than the name to differentiate between those objects.

Also, I stopped using activeDocument just to make my scripts more portable--it's not available in InDesign Server.

Thanks,

Ole

[_Dave_Saunders_]

Topics work that way in the UI. It was fortunate that I had studied the UI before I tried scripting this or I could have gotten into a terrible mess.

What I did was make topics whose names included the sort order (with a colon separator -- on the project in questions, colons are banned from topic names). That way I had a unique topic to work with. At the end, I then did a pass over all the topics, pulling out the sort order parts of those topics that had them.

Dave

[_Olav_Kvern_]

Hi Dave,

re: "Topics work that way in the UI."

Not...really. What we think of as a single topic appears as multiple topics to InDesign. Changing the subtopics or sort order, in essence, creates another topic. This is why trying to get all of the topics by a given name fails--unless you take the step you took. In essence, ItemByName doesn't really work with topics, because what we see in the UI and in the generated index is not the way that InDesign sees them. We really need to revisit indexing scripting.

[Edit: I somehow managed to say this all wrong. What I mean is that adding sort orders adds topics. Adding subtopics does not add topics. Apart from topics added by adding sort order strings, there is only one topic of a given name in an index.]

Thanks,

Ole

[_Dave_Saunders_]

I've just initiated this page:

http://www.niemannross.com/developer/wiki/index.php?title=InDesign_JS_Object_Model_Tables

with descriptions of two bugs associated with converting text to tables when the text is less than a paragraph.

Dave

[_Krishna_Vardhinedi_]

hi

[_Dave_Saunders_]

I guess this was inevitable but yesterday evening I was playing around with a script to work on windows, see:

http://jsid.blogspot.com

for a discussion. (First entry for months -- I did say it would be sporadic, but this was a long lay-off.)

Anyway, it occurred to me that perhaps I could get around the bug in app.activeDocument by instead working with:

app.activeWindow.parent

but this has the same bug. If you have two documents open with the same name and one of them is the activeDocument, it delivers the most recently opened which is not necessarily the parent of the activeWindow.

Interestingly, you'll get the wrong answer even with this:

app.activeWindow.selection[0].paragraphs[0].contents

Assuming a text selection, this will give you the contents of the text frame in the front window of the most recently opened document and not the front document.

This is a tad surprising because:

app.activeWindow.toSpecifier()

includes an id number. I get:

/document[@name="Test.indd"]/layout-window[@id=1363065]
/document[@name="Test.indd"]/layout-window[@id=1363222]

for the two documents I'm testing with. Apparently, those ids are not helping the scripting engine sort out which window is which. I wonder what happens if I open a second window for the documents?

Oh wow! It really gets squirrelly. If you make the new window and bring it to the front but fail to make a selection in it and then run:

app.activeWindow.selection[0].paragraphs[0].contents

you'll get an error that the object is undefined. This is true even though the other windows do have a selection. This means that at this point in the proceedings, it is looking at the right window.

But if you then make the selection and rerun the script, it will deliver to you the contents of the text in the wrong window.

This all stems from the fact that documents don't have an id property. Had they, the whole issue would go away because the specifier would use the id and not the ambiguous document name.

Dave