20.4 Loading Scripting Additions

To be usable, a scripting addition must be present in the correct location on the machine where a script will compile or run. This means that scripts relying on third-party scripting additions are not particularly portable. You might write a script that depends on some scripting addition, and then distribute it to others without remembering to provide the scripting addition on which it depends. This can easily happen by accident, because scripting addition terminology appears to you, the programmer, to be part of the AppleScript language. Once again, Script Debugger is especially helpful here; it can list the scripting additions on which your script depends, and will even look them up on http://macscripter.net for you.

You might provide, along with your script, any third-party scripting additions on which the script depends. Two problems then remain:

• Osaxen are not loaded from just any old location; to be seen at all, they must be in a Library/ScriptingAdditions folder.

• Osaxen are loaded when the AppleScript scripting component instance is created and starts up.

So the user must install the extra scripting additions in the correct place before running your script. A script might, at runtime, move a scripting addition file into a ScriptingAdditions folder, but it's too late, since the AppleScript scripting component instance has already been created, and any scripting additions that are going to be loaded have already been loaded.

Under Mac OS X 10.3 ("Panther"), a solution to this problem has finally been provided. Save your script as an Application Bundle; then open the bundle with Show Package Contents and create Contents/Resources/Scripting Additions, and copy any needed osaxen into this folder. Now this applet will run on any Panther machine.

There is also a trick that allows your script to force osaxen to be loaded again, while the script is running. Here it is:

try
        tell me to «event ascrgdut»
end try

This raw Apple event, for which there is no equivalent English-like terminology, tells the current AppleScript scripting component instance to refresh its knowledge of scripting additions. It's enclosed in a try block because it will probably generate an error, but the error is spurious; the command works, and any osaxen that were installed since the scripting component was instantiated will be loaded.

So now we can write a script that installs a scripting addition on the fly and calls a command within it, all in one move. We still might not be able to call the scripting addition command using the English-like terminology, though, since the scripting addition was perhaps not installed at compile time. Here's an example using the Jon's Commands osax. If the osax isn't installed, we ask the user to find it for us, and we install it ourselves. We then call the ticks, a command within Jon's Commands, using the raw four-letter code:

try
        «event JonstikC»
on error -- evidently it isn't installed
        set jons to choose file with prompt "Please find Jon's Commands:"
        set sa to path to scripting additions from user domain
        tell application "Finder" to duplicate jons to sa
        try
                tell me to «event ascrgdut»
        end try
end try
display dialog («event JonstikC») -- 1974834