You can initiate a script outside Script Debugger and still debug it in Script Debugger. The script opens in Script Debugger and you can pause at breakpoints, resume or step through the script, and so forth. This is called external debugging.

It is often easier to use external debugging and test a script under the conditions in which it will actually run than to try to simulate those conditions artificially. A good candidate for external debugging is an applet, a folder action, an Apple Mail rule script, a BBEdit menu item script, or any script that is to be triggered automatically by some other application. External debugging is especially useful when parameters are supplied as part of the call that triggers the script, since it shows you what those parameters are.

It often happens that the host application triggers the script by calling into a handler. In that case, this handler becomes the current event. The current event indicator appears at the top of the script, and the call is recorded in the event history. You can then subsequently call the same handler again with the same parameters, directly from within Script Debugger.

To perform external debugging:

1. Save a compiled script in debug mode.

2. Trigger the script in some other application.

   The script opens automatically in Script Debugger if it wasn’t open already.

   If the script was already open in Script Debugger when it is triggered, it remains open after it finished. If it wasn’t already open in Script Debugger, then when the script finishes, it closes.

   If the script wasn’t already open in Script Debugger beforehand, the name of the script, in the script window’s title bar, will appear as the name of the host application with “(Debugging)” appended to it, as a sign that external debugging is proceeding in a temporary window.

Switching the Frontmost Application

Various preferences determine how Script Debugger will behave with regard to pausing, and with regard to bringing itself and the initiating application to the foreground:

• “Pause script when external debugging begins.” If checked, Script Debugger inserts a temporary breakpoint before the first executable line, and pauses there when the host application initiates the script. This gives you a chance to configure breakpoints, for example.

• “Restore active application when stepping/continuing.” If checked, the host application is brought back to the front when resuming after a pause.

• “Bring Script Debugger to foreground when scripts pause.” If checked, Script Debugger is brought to the front when the script pauses.

• “Bring Script Debugger to foreground when scripts ends.” If checked, Script Debugger is brought to the front when the script ends.

If you decide that Script Debugger should not bring itself to the foreground, you can still control debugging from within the host application by using the Mini Debugger.

Hands-On Example

Here’s an example, using an Apple Mail rule script. A rule script is structured like this:

using terms from application "Mail"
    on perform mail action with messages theMessages for rule theRule
        tell application "Mail"
            -- do useful things here
        end tell
    end perform mail action with messages
end using terms from

Compile that script, put it in debug mode, place a breakpoint on the “tell” line, save it, and then (in Mail) nominate this script as the Run AppleScript action in a Rule. Trigger the rule by selecting some messages and choosing Message > Apply Rules. Depending on the choices you made in the preferences, Script Debugger may now come to the front; in any case, it is paused at the breakpointed line. You can examine theMessages to see what messages Mail has matched up with your rule’s criteria. Moreover, perform mail action is the current event, and has been added, with these parameters, to the event history.