Volume Number: 21 (2005)
Issue Number: 2
Column Tag: Programming

AppleScript Essentials

by Benjamin S. Waldie

An Introduction to Handlers

In a previous article, you may remember that we discussed methods of writing AppleScripts to watch folders for incoming items to process. In each of the methods we discussed, we made use of handlers. This month, we are going to explore handlers in more depth. Since handlers are a fairly complex subject, the full scope of handlers will not be covered in this month's article. Rather, we will cover the basics of handlers. In future articles, we will discuss handlers in more detail.

What is a Handler?

A handler is a group of one or more AppleScript statements that are associated with a single command. As we will discuss, some handlers are user defined, and some are application, or system defined.

Once the command associated with a handler is invoked, the statements within that handler will execute. Handlers allow you to group your code into logical "chunks," which may be triggered, or called, over and over again within a script. By carefully constructing your handlers, you can make scripts very modular, giving you the ability to break the scripts apart and reuse the handlers again in future scripts. Many AppleScript developers store their handlers in code libraries. These libraries can then be loaded, and handlers within them can be triggered from other scripts.

Anatomy of a Handler

Let's take a look at a basic handler. The following handler may be used to display a basic dialog message.

on displayDialog()
   display dialog "This is code within a handler."
end displayDialog

Now, let's break handlers down into different parts, and examine how they are constructed.

Handler Definition

A handler definition refers to the handler itself. The following would be considered the handler definition from the previous example.

on displayDialog()
   display dialog "This is code within a handler."
end displayDialog

A handler definition always begins with the word on or to, which indicates to AppleScript that it is the beginning of a handler. In the example above, I chose to begin my handler with the word on. However, the method you choose to use is entirely at your discretion. You should use whichever word looks more acceptable to you.

The next part of the handler definition is the name of the handler, followed by any parameters to be passed to the handler by the script. For example:

displayDialog()

In many cases, you may need to pass information to a handler to be processed. To allow for this, handlers support input parameters. Handlers also have the ability to return data back to the script. For example, a handler may return a true/false value indicating whether or not it was successfully processed.

There are a couple different methods that you can use to specify input parameters, and we will discuss them shortly. In the previous example, the empty parentheses indicate that my handler does not require any parameters.

Following the first line of a handler definition are any AppleScript statements that should be executed by the handler. You may write as few or as many statements as you need, keeping in mind that they will not execute until the handler is called.

The final line of a handler definition always begins with the word end, followed by the name of the handler.

end displayDialog

To save time when writing a handler, you may write the word end, and when you compile your code, the handler name will automatically be inserted for you.

Handler Call

To call a handler from within a script, you must specify the name of the handler, followed by values for all of its parameters. The following is the call for the previous handler example:

displayDialog()

We'll look at calling handlers that use parameters shortly, as we explore parameters.

If you need to call a handler from within an application tell block, you must specify of me after the handler call, to indicate that the handler is to be addressed within the script, and not within the application. For example:

tell application "Finder"
   displayDialog() of me
end tell

Parameters

As previously mentioned, the first line of a handler contains the handler name, followed by any parameters to be passed into the handler. A parameter is a variable that is named in the handler definition, and is assigned a value when the handler is called. When calling a handler, all parameters are required, and must be specified. Handlers do not allow optional parameters.

There are two types of parameters that may follow a handler name - labeled parameters and positional parameters.

Labeled Parameters

Labeled parameters are parameters that are associated with labels in the handler definition. When the handler is called, these labels are used to determine which parameters are which. Therefore, when working with labeled parameters, you may pass the parameters through your handler call in any order you wish, so long as they correspond with the correct labels. The exception to this rule is that, in some cases, you may choose to assign a direct parameter, which is required to fall immediately after the handler name.

There are two ways that you can assign labeled parameters in a handler. The first is to assign the parameters using one of the following predefined labels: about, above, against, apart from, around, aside from, at, below, beneath, beside, between, by, for, from, instead of, into, on, onto, out of, over, since, through, thru, under. The label of may also be used, though only to define a direct parameter. If you add a direct parameter, using the label of, then you are required to have at least one or more additional parameters. The following is an example of a handler with labeled parameters:

to displayDialog of theText above theButtons aside from theIconNumber
   display dialog theText buttons theButtons with icon theIconNumber
end displayDialog

In the example above, the parameter theText is a direct parameter, as indicated by the label of. The parameter theButtons is associated with the label above, and the parameter theIconNumber is associated with the label aside from. The handler above would be called using the following line of code:

displayDialog of "Hello" above {"OK"} aside from 1

Again, since labeled parameters are associated with their labels, then you can rearrange the non-direct parameters, if desired. For example, the following handler call would function identically as the previous one:

displayDialog of "Hello" aside from 1 above {"OK"}

Another way to assign labeled parameters is to use custom labels. This is done by creating label definitions in the format labelName:parameterName, separating them by commas, and preceding them with the label given. Custom labeled parameters must follow any predefined label parameters. An example of a handler with custom labeled parameters is the following:

to displayDialog of theText given someButtons:theButtons, someIconNumber:theIconNumber
   display dialog theText buttons theButtons with icon theIconNumber
end displayDialog

In the example above, the parameter theText is a direct parameter, preceded by a predefined label. The remaining parameters are custom labeled parameters. The parameter theButtons is associated with the custom label someButtons, and the parameter theIconNumber is associated with the custom label someIconNumber. This handler can be called using the following line of code:

displayDialog of "Hello" given someButtons:{"OK"}, someIconNumber:1

Again, since this handler makes use of labeled parameters, the non-direct parameters may be rearranged, if desired:

displayDialog of "Hello" given someIconNumber:1, someButtons:{"OK"}

Positional Parameters

Another type of parameter that you can use when defining a handler is a positional parameter. Positional parameters are separated by commas, and do not contain any labels. Because they do not contain labels, they are identified by their position in the handler definition. Therefore, they must be listed in the same position when the handler is called. The following is an example of a handler that makes use of positional parameters:

on displayDialog(theText, theButtons, theIconNumber)
   display dialog theText buttons theButtons with icon theIconNumber
end displayDialog

The handler above may be called using the following line of code:

displayDialog("Hello", {"OK"}, 1)

Return Value

In some cases, a handler may return a value to the script that called it. This value may be placed into a variable for later usage. By default, a handler will return the result of the last AppleScript statement that executes within the handler, assuming that this statement produces a result. If desired, you may configure your handler to return a different value. For example, the following code returns the name of the button clicked in the dialog.

set theChoice to displayDialog()

on displayDialog()
   display dialog "Would you like to continue processing?" buttons {"Yes", "No"}
   return button returned of result
end displayDialog

Next, I could add additional code at the root level of my script to check the button that was clicked, now stored in a variable called theChoice, and take the appropriate course of action.

Within a handler, you may return a value at any time to cease further execution of that handler, or you may return no value to cease execution without returning a specific value. For example, the following handler will stop processing, returning no value, if the user clicks the "No" button.

displayDialog()

on displayDialog()
   display dialog "Would you like to continue processing?" buttons {"Yes", "No"}
   set theChoice to button returned of result
   if theChoice = "No" then return
   display dialog "Continuing..."
end displayDialog

Types of Handlers

There are two types of handlers in AppleScript - subroutine handlers and command handlers.

Subroutine Handlers

Subroutine handlers are groups of statements, which are defined by the developer, and called throughout a script, or from another script. Subroutines can be extremely useful if you need to perform the same exact task over and over throughout your script. For example, let's say that you need to display an informational dialog to the user 10 times throughout your script to let the user know what is occurring.

display dialog "Beginning next task..." buttons {"*"} 
   default button "*" with icon 1 giving up after 3

To display the above dialog 10 times, I could write out all of this code 10 times - or, I could write a handler 1 time.

on displayNextTaskMessage()
   display dialog "Beginning next task..." buttons {"*"} default 
      button "*" with icon 1 giving up after 3
end displayNextTaskMessage

Once written, this handler can be triggered from anywhere within my script. Rather than writing the entire lengthy line of display dialog code each time I need to display the dialog to the user, I can call my handler instead. The following code would call the displayNextTaskMessage handler.

displayNextTaskMessage()

In the example above, you may be wondering where the handler name "displayNewTaskMessage" came from. This is something that I defined myself when writing the handler. Remember, since subroutine handlers are defined by a developer, their names are user definable. So, I could have named this handler anything I wanted, as long as it was not the name of another existing handler in my script.

Command Handlers

A command handler is a group of statements that is triggered by a specific application or system related event.

Every AppleScript application contains an implied run handler. Any AppleScript statements at the top level of the script, excluding global variables, properties, other handlers, and script objects, fall within that run handler. If you prefer to make the run handler visible in your code, you may wrap these statements within an on run handler call. When the script is run, both methods will behave identically. For example, each of the examples below will perform the exact same function:

Example 1:

display dialog "Hello!"

Example 2:

on run
   display dialog "Hello!"
end run

As you can see, any code within the run handler of a script will be executed whenever the script is run. However, in some cases, you may want to execute code when other types of actions occur within your script.

The open handler may be used to initiate specific code when items are dragged and dropped onto a script in the Finder. For example:

on open theDroppedItems
   -- Process the items
end open

By adding an open handler into a script, and then saving that script as an application, the script will automatically accept dropped files and folders. It will also receive a new icon, indicating that it is now a drop script.

In the previous example code, the parameter theDroppedItems will contain a list of paths to any items dropped onto the script. If you want your script to only process folders, then you would need to add custom code within the open handler to determine which dropped items were folders, and process only these items.

Two other types of command handlers that may be added to an AppleScript application are the idle handler and the quit handler.

An idle handler is particularly useful when creating stay open AppleScript applications. In a stay open AppleScript application, by default, AppleScript will send the script an idle command every 30 seconds. At that time, any code within the idle handler will execute. For example, if I save the following code as a stay opened AppleScript application, and trigger it, the script will beep every 30 seconds:

on idle
   beep
end idle

Though the default time period between idle messages is 30 seconds, I can change this behavior if desired, by returning an integer value indicating how many seconds of a delay should occur before the next idle. In the following example, the script would beep every 10 seconds.

on idle
   beep
   return 10
end idle

The quit handler may be used in order to execute code when the script quits, whether manually quit by the user or not.

on quit
   display dialog "Task complete."
end quit

Example Handlers

Now that we have covered the basics of handlers, let's take a look at some example handlers, which may be useful to you as you write scripts in the future. Each of these handlers has been written generically, so that you can use it in virtually any script in the future.

The following handler will make a new folder in a specified output folder, using a specified name:

on makeNewFolder(theNewFolderName, theOutputFolder)
   tell application "Finder" to make new folder at folder theOutputFolder with properties 
      {name:theNewFolderName}
end makeNewFolder

The following handler will delete a folder of a file:

on moveItemToTrash(theItemPath)
   tell application "Finder" to delete item theItemPath
end moveItemToTrash

The following handler will mount an afp volume:

on mountVolume(theVolumeName, theServerIPAddress, theUserName, thePassword)
   mount volume "afp://" & theUserName & ":" & thePassword & "@" & theServerIPAddress 
      & "/" & theVolumeName as string
end mountVolume

In Closing

Again, handlers are a fairly complex aspect of AppleScript development for many users. Today, I use them regularly, and I try to make them as modular as possible. My theory is that if I write code to perform a specific task, such as opening a document in QuarkXPress, then I don't want to ever write that code again. Rather, I store the handler for later usage in future scripts, and the next time I need to perform the task, which could be a year down the line, I simply add the handler into my new script.

I encourage you to begin using handlers more in your scripting, as it will benefit you greatly. We'll discuss other aspects of handlers in more detail in future articles. In the meantime, for additional information about handlers, you may want to check out an AppleScript book, or browse the AppleScript Language Guide at <http://developer.apple.com/documentation/AppleScript/>.

Until next time, keep scripting!

Benjamin Waldie is president of Automated Workflows, LLC, a firm specializing in AppleScript and workflow automation consulting. In addition to his role as a consultant, Benjamin is an evangelist of AppleScript, and can frequently be seen presenting at Macintosh User Groups, Seybold Seminars, and MacWorld. For additional information about Benjamin, please visit http://www.automatedworkflows.com, or email Benjamin at applescriptguru@mac.com.