33

AppleScript

AppleScript, like UserTalk, is a programming language which sends Apple events to drive other applications. It is a product of Apple Computer, Inc. Frontier scripts can be written in AppleScript. That's possible because Frontier is an Open Scripting Architecture (OSA) -compliant scripting program: it can run scripts in any OSA dialect present on the machine, and AppleScript is an OSA dialect. (For more about the OSA, see Chapter 34, Driving Frontier from Outside.)1

This chapter describes how to write and run AppleScript scripts in Frontier. It does not teach the AppleScript language, because someone who doesn't know AppleScript already won't derive, from learning AppleScript, any benefit that Frontier doesn't already offer through UserTalk.2

This chapter also discusses how to call an OSAX, which is an AppleScript language extension. An OSAX can add functionality to UserTalk without the use of AppleScript, so this part of the chapter may be of use even to readers who do not know AppleScript.

AppleScript Scripts

The language of a script object is revealed in a rectangular box at the bottom of its edit window. That box is actually a popup menu, from which you can choose a different language. On most machines, the choices will be AppleScript and UserTalk.

In an AppleScript script, lineation is meaningful according to the usual rules of AppleScript, but indentation is not; indent as desired for legibility. You can check a script's correctness by pressing the Compile button; if there is an error, you can find it with the Go To button in the error message dialog. There is no Debug mode.

AppleScript scripts run within Frontier just as they would in another context. But note that properties are not static after execution terminates; instead, store static values in the database, as explained next.

UserTalk and the Database

You can call an AppleScript script from a UserTalk script or from another AppleScript script.

If you call an AppleScript script from a UserTalk script, or if you press the Run button in an AppleScript script edit window, top-level commands are executed, or a run() handler is executed if there is one - there cannot be both, but there can be other top-level handlers, since a handler is not an executable command.
If you call an AppleScript script from another AppleScript script, its eponymous handler is called - if there isn't one, an error results. There can be other top-level commands, but they won't be executed.

So, for example, suppose workspace.testing contains an AppleScript script that goes like this:

on testing()

    display dialog "You called me from AppleScript."

end

display dialog "You called me from UserTalk, or with the Run button."

Now suppose we have another script, perhaps workspace.testing2, which says:

workspace.testing()

Let the language popup in workspace.testing2 say UserTalk. If we press the Run button in workspace.testing2, we see: "You called me from UserTalk, or with the Run button." But if we now change the language popup in workspace.testing2 to be AppleScript and press its Run button again, we see: "You called me from AppleScript."

UserTalk script objects in the database can be called from an AppleScript script. There is no need for a tell block; you are already inside Frontier, so you can call UserTalk verbs directly.

AppleScript scripts cannot speak of any other database objects, so two special verbs are provided to allow database entry values to be manipulated.

To set or get a database entry's value from an AppleScript script:

db.set (entryPathString, value)

db.get (entryPathString)

In general, UserTalk datatypes and AppleScript datatypes match, so you can hand values between AppleScript and UserTalk as parameters in a verb call, or get and set database entries, without difficulty.

AppleScript on the Fly

Up to this point, we have been assuming that the AppleScript script is prepared and living in the database in advance. Sometimes, though, this is too much trouble or is not feasible: it is desired, instead, to generate and execute a few lines of AppleScript on the fly, from within a UserTalk script. This is easy to do with a utility script.

The approach taken here is: given a string, to create an AppleScript script object, put the lines of the string into it, and call it.

*Example 33-1* *doAsAppleScript( )*
on doAsAppleScript(s)
local (sc); new(scriptType, @sc)
script.setLanguage(@sc, "AppleScript")
target.set (@sc)
local (x)
for x = 1 to string.countFields (s, cr)
op.insert (string.nthField(s, cr, x), down)
return sc()
« here's a little test
doAsAppleScript ("display dialog \"Howdy.\"")

OSAXen

An OSAX is an AppleScript language extension. AppleScript scripts can call OSAXen transparently;3 when an OSAX lives in the Scripting Additions folder, its commands become part of the AppleScript language.

UserTalk scripts, too, can call OSAXen. They do this by way of glue. This extends the UserTalk language by permitting it to take advantage of the many existing OSAXen. (For other ways of extending UserTalk, see Chapter 23, Extending the Language.)

To generate UserTalk glue for an OSAX, do this. First, make a temporary copy of the OSAX file, and rename the copy as you want its database entry to be named. The new name should contain no spaces or other nonstandard characters. Now, in Frontier, choose Load an OSAX from the AppleScript submenu of the Main menu, or drop the OSAX file onto Frontier's icon. This will create a glue table for the OSAX in system.extensions, and will also load the OSAX itself as a binary into the glue table. Now you can delete the renamed copy of the OSAX.

At this point you have a choice. You can simply proceed to use the OSAX by calling the glue verbs. But there are disadvantages to this approach. Some OSAXen, for one reason or another, won't work properly unless they live as files in the Scripting Additions folder: for example, they expect themselves to be there, or they need to be able to modify themselves, or they require additional resources contained in the files.

So you might want to tweak the glue to call the copy of the OSAX in the Scripting Additions folder rather than the one in the database. To do so, go through the script objects in the glue table, changing the first parameter in their appleEvent() calls to 0. This, as explained Chapter 32, Driving Other Applications, sends the Apple event to the system, which passes it to the system-level copy of the OSAX.

If you distribute scripts that call OSAXen, don't forget that they won't work unless those OSAXen are installed on the user's machine.

Import/Export

An AppleScript script object can be exported as a file which can be opened or run by other AppleScript scripting programs, such as Script Editor, Script Debugger, and OSA Menu. To do so, choose Export from the Main menu, and choose Script Editor Format from the first popup in the Export dialog.

An AppleScript file which is already in Script Editor format (because, for instance, it was created by Script Editor) can be imported into the database directly. Just choose Load AppleScript from the AppleScripts submenu of the Main menu, or drop the file onto Frontier's icon. Frontier can import an uncompiled script, a compiled script, or an AppleScript "application"; the object is loaded into the workspace table. A folder of such files can be imported all in one move with the Load Folder command; a subtable is created in the workspace table, and the files are imported as its entries.

If you own Script Debugger, you can use it to edit (and debug) AppleScript script objects in the Frontier database. See Chapter 35, External Editors.

1. Other OSA dialects besides UserTalk and AppleScript are QuicKeys Script (present if QuicKeys is loaded at startup), tclScript, and MacPerl. This book does not discuss these dialects.

2. To learn more about AppleScript, see both http://www.applescript.apple.com/default.html and http://devworld.apple.com/dev/techsupport/insidemac/AppleScriptLang/AppleScriptLang-2.html.

3. "OSAXen" is the correct plural of "OSAX." Don't ask me how I know; I know.