11.7. Me

The keyword me represents the current scriptthe script or script object that is running the code where the keyword me appears. (In situations where you would say of me after a word, you may say my before that word instead.) Thus:

script myScript
    me -- «script myScript»
end script
run myScript
me -- «script», the anonymous top-level script
parent of me -- «script AppleScript»

See also "The Implicit Parent Chain" in Chapter 8.

We saw the keyword me used earlier (Chapter 8) as a way to force AppleScript to interpret a term as belonging to the current script object, so that it will use the inheritance chain.

When targeting an application in a tell block, me can be helpful as a specifying that the target should be your script instead. For example, this doesn't work:

on reverseString(s)
    set text item delimiters to ""
    return (reverse of characters of s) as string
end reverseString
tell application "Finder"
    set name of folder 1 to reverseString(get name of folder 1)
    -- error: Finder got an error: Can't continue reverseString
end tell

When we come to the handler call reverseString( ) in the next-to-last line, the target is the Finder. So AppleScript passes it along to the Finder. The Finder doesn't know what to do with this message. The target for reverseString, and only reverseString, needs to be the current script. This is a job for me (a "can't continue" error usually is):

    set name of folder 1 to my reverseString(get name of folder 1)

But me won't also resolve a terminology clash between a term defined by the target and a term within your script. In that case, you'll have to use pipes (vertical bars) around the term, to prevent its resolution by the target dictionary. For instance, how might I refer to the global variable home in a tell block directed at the Finder, which has a home attribute? I can try using my, but I just get a mysterious error message:

set home to "Ojai"
tell application "Finder"
    get my home -- error: Can't make home directory into type reference 

end tell

The problem is not that my failed to retarget the message. It did retarget it! But the term home is still being resolved in accordance with the Finder's dictionary. So when the message arrives at my script, it doesn't speak of my variable home, but of some Finder-based attribute that my script doesn't know how to interpret. Use of pipes solves the problem:

set home to "Ojai"
tell application "Finder"
    get |home| -- "Ojai"
end tell

There is no need for my, because the pipes cause AppleScript to take home as a name in scope within the script, and so it targets the script rather then the Finder.

Occasionally you may have to use pipes around the name of a handler call, too. In this case you need me as well as the pipes, because a handler call is always directed at the target unless you explicitly say otherwise. For example, here we'd like to call our own reveal, but the message goes to the Finder instead:

on reveal(what)
    display dialog (get name of what)
end reveal
tell application "Finder"
    reveal(file 1) -- the Finder highlights the file's icon
end tell

Adding my just causes a mysterious error message:

on reveal(what)
    display dialog (get name of what)
end reveal
tell application "Finder"
    my reveal (file 1) -- error: Expected expression but found command name
end tell

Using pipes without my causes a different error message:

on reveal(what)
    display dialog (get name of what)
end reveal
tell application "Finder"
    |reveal|(file 1) -- error: Finder got an error: Can't continue reveal
end tell

The solution is to use both:

on reveal(what)
    display dialog (get name of what)
end reveal
tell application "Finder"
    my |reveal|(file 1)
end tell

The trouble is that the Finder has its own reveal command. The pipes suppress the use of the Finder's terminology; the my routes the message to your script instead of the Finder. If you use me but no pipes, the message is sent to your script using the Finder's terminological encoding, and your script doesn't understand it; if you use pipes but no me, the message is sent to the Finder with no terminological encoding, and the Finder doesn't understand it.