• Choose a category
• All
• Classic-Fiction

get name of folder 1

Then it uses the result to set the value of oldname within your script. There is a clear division of labor: the Finder does not somehow lay hands on any of your script's variables.

But handler calls are different. A handler call will always send a message to the target. This won't work:

on whatNumber( )

return 1

end whatNumber

tell application "Finder"

get folder whatNumber( ) -- error: Finder got an error: Can't continue whatNumber

end tell

The Finder is sent the whatNumber message, but it knows of no whatNumber command. (The section "Me," later in this chapter, will provide the solution to this problem.)

Nested Targets

The innermost target of a command is the target. Once AppleScript, working its way outward from a command, has determined a complete target, it stops, ignoring any further ofs or tells that surround it. Consider, for example, the following:

tell application "iTunes"

tell application "Finder"

count folders

end tell

end tell

iTunes is not in fact targeted in any way here; no message will be sent to it when the code runs. AppleScript works its way outwards from the count command until it reaches the Finder; now AppleScript has assembled a complete target, and stops. In fact, if you try to write the same thing this way:

count folders of application "Finder" of application "iTunes"

AppleScript literally throws away the mention of iTunes after decompilation:

count folders of application "Finder"

The direct object has primacy in this regard. It always has the potential to constitute a complete target and override all surrounding ofs and tells. For example:

tell application "Finder"

count "howdy"

end tell

The string "howdy" is a complete target, and no message is sent to the Finder.

Get

The default command is get. In effect, a sentence or clause with no verb is assumed to have get as its verb. So, for example:

tell application "Finder"

name of folder 1

end tell

The get command is supplied here and is the actual message sent to the Finder. It's exactly as if you had said get explicitly:

tell application "Finder"

get name of folder 1

end tell

One even sees code written like this:

tell application "Finder" to name of folder 1

AppleScript can also supply get in the middle of a line where needed. As we have already seen, this code:

tell application "Finder"

set oldname to name of folder 1

end tell

is actually treated by AppleScript as if it said this:

tell application "Finder"

set oldname to (get name of folder 1)

end tell

Do not imagine, however, that it makes no difference whether you ever say get, and that you can blithely omit it. On the contrary, it's probably better to err in the other direction and say get whenever you mean get. There are no prizes for obfuscated AppleScript, and you're most likely to confuse yourself (and impress no one else) if you get into bad habits. More important, omission of get from expressions of any complexity can cause runtime errors. For example, this:

tell application "Finder" to display dialog (name of folder 1)

-- error: Finder got an error: Can't make name of folder 1 into type string

is not the same as this:

tell application "Finder" to display dialog (get name of folder 1) -- Mannie

In the first example, name of folder 1 is a reference to an attribute; that's not something that can be displayed by display dialog, so we get an error. In the second, the get command fetches the value of that attribute, a string, and all is well. AppleScript programmers like to say that get resolves references .

Sometimes, just the other way around, you don't want references resolved. This works (the first word of the document is deleted):

tell application "TextEdit" to delete word 1 of document 1

But this doesn't work (there is no error, but nothing happens):

tell

application "TextEdit" to delete (get word 1 of document 1)

In the second case, get resolves the reference, effectively evaluating the expression and yielding a string (the text