AppleScript_ The Definitive Guide - Matt Neuburg [185]
Some applications are particularly badly behaved in this regard. A good example is Eudora. There is a mailbox class in Eudora, but how can you speak of any particular mailbox? The only place a mailbox element appears in the dictionary is under the mail folder class. But in fact not every mailbox in Eudora is in a mail folder, so how can you ever speak of such a mailbox at all? It looks impossible. Yet it turns out (after some experimentation) that you can speak of a mailbox directly:
tell application "Eudora" to count messages of mailbox "In"
That's nice, but if it's legal, why doesn't the dictionary say so? Why isn't mailbox an element of the application class? In Eudora's dictionary, mailbox is an orphan class.
A dictionary may also simply omit pieces of the puzzle, such as not bothering to list all of a class's elements. If you read Appendix A you'll see me spending much of my time discovering that in FrameMaker an anchored frame can be an element of a paragraph or of a document. This discovery comes as a relief, and makes the ultimate solution possible, but the dictionary says no such thing; only experimentation reveals the facts.
Something quite similar happens in the Finder's dictionary. The dictionary quite clearly states that a Finder window has no elements (and it doesn't inherit from anything that has elements). Yet the following is both legal and useful:
tell application "Finder" to get item 1 of Finder window 1
Thus an application can have a perfectly reasonable object model in its head, as it were, but fail to reveal it to you in its dictionary. In the dictionary, the object model is defective. And the dictionary is all you've got.
Defective Element Specifiers
There are many ways to refer to an element (see "Element Specifiers" in Chapter 11), but you can't be sure from the dictionary which ones are implemented for any particular element. The dictionary format has a place for this information, but developers often fail to provide it correctly, leaving you to discover the truth by experimentation. Even if the correct information is present in the dictionary, the Tiger version of Script Editor omits it altogether from its dictionary display.
For example, according to the Finder's dictionary, a container's file elements can be specified by name and by index. But those are not, in fact, the only specifier forms that work. The range specifier form works too:
tell application "Finder" to get files 1 thru 2 of folder 1
The Finder also lists in its dictionary specifier forms that do not work. For example, the dictionary says you can specify a folder by ID. But you can't get a folder's ID, so that's not true.
An application can implement element specifier forms in bizarre ways. For example, in Eudora, you can't say this:
tell application "Eudora" to get mailbox 1 -- error: Can't get mailbox 1
But you can say this:
tell application "Eudora" to get name of mailbox 1 -- "In"
Or this:
tell application "Eudora" to count messages of mailbox 1
So you can't get a mailbox by index, but you can get its name and messages by index? What's the underlying logic here? Weirdest of all, you can't say this:
tell application "Eudora" to count mailboxes -- error: Can't get every mailbox
So how are you supposed to learn how many mailboxes there are? You can't. So how can you cycle through all mailboxes? As far as I know, the only way is to keep cycling by index number, incrementing the index, until you get an error.
Boolean test specifiers are, of course, the most chancy, but when they work they are wonderfully elegant and powerful. A simple listing in the dictionary could never tell you everything you want to know about boolean test specifiers, because it can't possibly let you know all the various tests that work and don't work; so experimentation is your only option. The same goes for properties of multiple references, such as "get name of every..." (Chapter