AppleScript_ The Definitive Guide - Matt Neuburg [174]
tell application "iTunes"
display dialog (kind of source 1 as string) -- library
end tell
The kind property of a source in iTunes is an enumeration, so what comes back from iTunes here is a constant. A constant can't be shown by display dialog, but it can be coerced to a string (Chapter 17) and then shown. iTunes does not implement this coercion, so AppleScript performs it (see "Coercion by a Scriptable Application" in Chapter 14). In a script editor application, it can do this satisfactorily, thanks to decompilation: AppleScript has access to iTunes's dictionary, so it knows that the English-like term for this constant is library and can coerce it to the string "library". But when executing in a script runner or an applet, there is no decompilation, and AppleScript is left holding the bag. All it knows is the four-letter code for this constant, because that's what came back from iTunes. It has no way to translate it into English, so it coerces the four-letter code to a string:
tell application "iTunes"
display dialog (kind of source 1 as string) -- «constant ****kLib»
end tell
The workaround in this situation is to construct a table of constants and their string equivalents and perform the translation yourself:
set R to {«class kACD»:"audio CD", «class kLib»:"library", ¬
«class kTrk»:"track listing"}
tell application "iTunes"
set k to (get kind of source 1)
display dialog (get property k in R) -- library
end tell
(The next-to-last line uses Late Night Software's List & Record Tools scripting addition to make the lookup process more elegant. It allows a record property to be expressed as the value of a variable.)
All this assumes, of course, that you have a way to learn what the four-letter codes are. One very easy way is to use Script Debugger, whose dictionary display and Apple Event Log allow you to view the four-letter codes directly. Alternatively, if the dictionary is a text file, you can read it in any text editor; if it is (or if you can turn it into) an 'aete' resource in a resource fork, you can read it with the freeware Eighty-Rez.
Multiple-Word Terms
Many terms, especially commands in scripting additions, consist of multiple words . An example frequently used in this book is display dialog. You might think that such a term would present extra challenges for resolution, but in actual fact just the opposite appears to be the case; multiple-word terms are a good thing:
You can't make one
Terms that you create in a script can't contain spaces unless surrounded by pipes—and pipes mean that no dictionary will be consulted. Therefore the probability of your creating a term in a script that clashes with a dictionary-based multiple-word term is zero.
Clash is improbable
The more words a term consists of, the more likely it is that this term is unique among all dictionaries. This is especially important with scripting additions, whose terms are globally visible; for this reason, well-behaved scripting additions tend to use multiple-word commands.
There is no clash with single-word terms
This is the really surprising part. Consider, for example, the scripting addition command set the clipboard to. Even though set...to is a command, and the is usually ignored, and clipboard could be a variable name (and is in fact a property defined by AppleScript), no confusion arises:
local clipboard, tester
set clipboard to "Mannie" -- sets the variable clipboard
set the tester to "Moe" -- sets the variable tester (ignoring "the")
set the clipboard to "Jack" --sets the system scrap
Though I don't know the details, a natural explanation of AppleScript's success in resolving multiple-word terms would be that it tries the longest possible combinations of words first.
A multiple-word property name can be a little troublesome.