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.