Script Debugger lets you run individual handlers in a script. This can be a valuable testing and debugging technique.

Standard Event Handlers

Consider the applet script in the illustration below. If you simply run this script, you’ll see the “Howdy!” dialog. That’s because what you’ve just run is the run handler. But what if you want to test the idle handler? Script Debugger lets you do this. To do so:

• Choose Script > Execute > Idle. Alternatively, hold down the mouse down on the Execute button in the toolbar. A popup menu appears, and you can choose Idle in this menu.

This does two things:

1. It actually runs the idle handler. (To prevent this, hold down the Shift key as you choose Idle.)
2. It sets the “default” handler of this script (also called the script’s current event) to be the idle handler.

The menu you are using here — the menu that is attached hierarchically to Script > Execute, and that appears when you hold down the mouse down on the Execute button — is called the Event Handler menu. It is attached to Script > Execute, Script > Trace, Script > Step Over, and Script > Step Into, as well as to the Execute, Step Over, and Step Into toolbar buttons.

The standard event handlers listed in these menus are the five standard applet events, the Folder Actions suite events (defined in StandardAdditions.osax), and the Digital Hub Actions suite events (defined in Digital Hub Scripting.osax).

Note: If your script has one of these event handlers, but the corresponding menu item is not enabled, compile the script. That should fix it.

The Current Event

What does it mean to say that the script’s current event is the idle handler? It means that the next time you execute the script, you’ll execute the idle handler automatically. This behavior is there to make it easy for you to test an event handler, make a change in the script, and then test the event handler again. But it involves a change in the basic behavior of your script, since normally when you run a script, it’s the run handler that runs.

To alert you to the fact that there is a current event, the current event is checked in the menu, and a current event indicator appears below the toolbar of your script window:

To revert the current event to being the run handler once again, choose Script > Execute > Run (again, hold down the Shift key to prevent the run handler from running when you do this). The current event indicator goes away.

Parameters and the Event History

The open handler and the event handlers defined in the Folder Actions and Digital Hub Actions suites are a bit different, because they expect parameters, which are aliases or files. For example, an open handler expects a list of aliases to the files and folders. And an adding folder items to handler expects two parameters, an alias to the watched folder and a list of aliases to the added files. Script Debugger helps you even further with this sort of handler.

Such a handler is listed in the Event Handler menu with an ellipsis (…) after its name. When you choose such a handler from the menu, Script Debugger puts up a dialog where you can select files and folders. An appropriate parameter or parameters will then be passed to the specified handler.

In the case of adding folder items to and removing folder items from, what you’re supplying in this dialog is the second parameter, the item(s) that are allegedly being added or removed. Script Debugger will then use the containing folder of the item(s) as the first parameter, the watched folder.

In the case of just the open handler, there is another alternative. Drag-and-drop files and folders directly from the Finder into your script. If your script has an open handler, one of the options in the resulting dialog is to invoke the open handler with these Finder items as parameter.

Script Debugger remembers each alias or list of aliases produced in this way, along with the event handler it is to be passed to. Script Debugger adds this information to the bottom of the Event Handler menu, and makes it the current event. This list of remembered event handlers and parameters is called the event history.

Thus, the next time you want to test this handler with these same parameters, you just choose it from the event history (or, if it is the current event, click the Execute button). And of course you can switch from testing one handler/parameter set to testing another, by choosing that menu item from the event history.

The event history is remembered until you close the script window; or you can deliberately remove it by choosing Clear Menu (which is always the last item in the Event Handler menu if there is an event history).

A continue statement in an event handler called in this way will generate an error in Script Debugger. This is deliberate and may be safely ignored. The technical reason is that if, for example, we permitted the continue quit statement in your quit handler to execute, Script Debugger itself would quit!

Other Handlers

What if the handler you want to test is not one of the standard event handlers already listed in the Event Handler menu? No problem. You can still call just the specific handler, and it is added to the event history so that you can easily call it again with the same parameters. To do so, you take advantage of Script Debugger’s scriptability, which allows one script to call a handler in another script.

Actually, you can do this for standard event handlers as well. For example, in the case of the open handler discussed above, you could open a new script window in front of the applet script (this ordering is to make sure that the applet script is document 2) and, in the new window, run this script:

    tell application "Finder" to get disk 1 as alias
    tell document 2
        open result
    end tell

This calls the open handler in the applet script and adds it, with this parameter, to the applet script’s event history.

However, you are more likely to use this technique to test a top-level user handler. For example, suppose you have a complex script containing this top-level handler:

    on justName(s)
        set text item delimiters to ":"
        return last text item of s
    end justName

You can check whether this handler is behaving correctly, without the inconvenience and overhead of running the rest of the complex script. Make a new empty script window in front of the complex script, and enter and run this script:

    tell document 2
        justName("hey:ho:nonny nonny no")
    end tell

This calls justName in the complex script, and adds the call with this parameter to the event history. Now you can repeatedly test this handler and develop it without altering the rest of the complex script.

Similarly, during external debugging, an entry-point handler called by the external application is added, with its parameters, to the target script’s event history. (This happens only if the script is in debug mode, though, since otherwise this would not be external debugging.)