Scripts Menu
Volume Number: 12
Issue Number: 2
Column Tag: Open Scripting Architecture
Attaching a Scripts Menu 
An introduction to using the OSA in PowerPlant
By Jeremy Roschelle
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
A fully AppleEvent-savvy application is scriptable, recordable, and attachable. In a
scriptable application, any user can automate tasks, interconnect applications, and
extend the capabilities of your application. A recordable application generates a script
by observing the user’s actions. Yet these capabilities prove worthless if users have
no easy way to execute their scripts. Unfortunately, Apple did not provide any
standard human interface for attaching scripts to an application. And although the
PowerPlant framework provides excellent support for scripting and recording, it
provides no recipes for customizing your application to launch scripts. This article
execute scripts (see Figure 1).
At first, implementing a script menu looks complex: it requires interacting with
PowerPlant, the Menu Manager, the File Manager, the Open Scripting Architecture
(OSA), and the scriptable Finder. On the bright side, PowerPlant and the OSA provide
excellent modular, easy-to-use interfaces [see Jeremy’s article, “Powering Up
AppleEvents in PowerPlant”, MacTech Magazine, 11:6 (1994) 33-46 - man]. In
this article, I’ll present an implementation of an extension to the PowerPlant
framework that that can compile and execute scripts from a standard pull-down menu.
This script menu provides a relatively complete implementation of attachable scripts:
it loads scripts at launch time from a “script menu items” folder, automatically
supplies Balloon Help for each menu item, and can open a script for editing in the
Script Editor. This article will also show you how easy it is to use OSA to compile and
execute scripts.
Figure 1. The Script menu
The implementation also strives to use the capabilities of PowerPlant, C++, and
AppleEvents to achieve modularity and encapsulation. For example, we use the
LAttachment mechanism to encapsulate all the code for handling the script menu into a
re-usable class. Likewise, we introduce a C++ iterator class for scanning through
items in a folder. Finally, we use AppleEvents to connect our script menu to external
applications that provide script editing services, thus avoiding the need to embed a
script editor ourselves.
OSA Basics
From the user’s point of view, a script is a small program written in AppleScript or
another OSA dialect. From the programmer’s point of view, a script is a data type
containing code that the OSA can execute. The process of compiling a script reconciles
these views: compiling converts AppleScript statements into an executable data type.
As a programmer, you manipulate a script as a Handle to some script data. The
easiest way to get such a handle is to get the 'scpt' resource out of a ScriptEditor
document. There is one 'scpt' resource in each ScriptEditor document, storing the
script compiled by the user.
To run a script, you first load the script data into OSA. This results in an OSAID,
a token that refers to the loaded script. The process of loading is relatively slow (a
second or two on my Quadra 660AV). Once a script is loaded, running it is fast (small
scripts seem as fast as hard-coded commands in my application). To execute the
script, you pass the OSAID to the OSAExecute function. When you are through with a
script (or any value returned by OSA), you dispose of its OSAID to free up the
associated memory.
To hide the ugly details, I wrapped my code in a utility class with static methods:
UScripting::Initialize
void UScripting::Initialize()
{
// sComponent is a static class member of type ComponentInstance
if (sComponent == nil)