External debugging is a mechanism that lets you run a script elsewhere but summon Script Debugger to debug the script anyway. To use it:

• Save a compiled script while the script is in debug mode. Now trigger that script in some other application. The script opens in Script Debugger, optionally paused before the first executable line. Now you can proceed to debug the script in the normal way.

It makes a difference whether the script is open in Script Debugger when it is triggered. If it is, then when the script finishes executing in debug mode, it remains open. If it isn’t, then when the script finishes, it will close.

If the script was not 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.

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. Moreover, the handler and parameters are remembered as part of the call history. In subsequent testing, therefore, you can call the same handler again, yourself, with the same parameters.

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

You can compile that, 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. When the rule is triggered (which you can do by selecting some messages and choosing Message > Apply Rules), Script Debugger comes to the front, paused at the breakpointed line. Now you can examine theMessages to see what messages Mail has matched up with your rule’s criteria. Moreover, the call to perform mail action has been added, with these parameters, to the event history. You can choose it to make it the current event and run the event handler repeatedly with the same parameters without switching to Mail.

Here’s another example, using BBEdit’s menu item script mechanism. A BBEdit menu item script is structured like this:

on menuselect(theMenu, theItem)
    return false
end menuselect

Save that, in debug mode, with the name New•Text Document, in ~/Library/Application Support/BBEdit/Menu Scripts. Leave it open. Now switch to BBEdit and choose File > New > Text Document. This triggers our script; BBEdit calls our menuselect() handler. And the call to menuselect(), with the actual parameters, is added to the event history. You can thus repeat the call, with those same parameters, without switching to BBEdit.