Script App Example
Volume Number: 9
Issue Number: 8
Column Tag: Scripting
Related Info: Apple Event Mgr
AppleScript Script Applications 
An example of an AppleScript application
By Jens Alfke, Apple Computer, Inc.
Note: Source code files and sample scripts accompanying this article are located onMacTech CD-ROM or source code disks.
About the author
Jens Alfke is a member of the AppleScript engineering team at Apple Computer,
where he works on the script editor, the script application framework, and the OSA
component API. He would like to thank a lot of obscure, alienated British musicians
whose guitar noise made his accomplishments possible and bearable.
Figure 1: Two script applications; one droppable, one not
The Script Editor that comes with AppleScript™ allows you to save scripts as
tiny applications. By “tiny” I mean really tiny: a base size of less than 2k, plus the
data size of the script and its description text. A small but useful script application
might weigh in at about 8k. (For the curious: the actual code that runs the applications
lives as a component in the AppleScript extension. Each script app just has a stub that
dynamically links in the real code.)
In the simplest case, the script runs when the application is launched - whether
by a double-click, Apple menu choice, or by being in the Startup Items folder - and
then the application immediately quits. You can also make script applications that can
have file, folder or disk icons dropped on them and then operate on those items. But
much more is possible! This article describes:
• How script applications handle Apple events
• Stay-open applications
• Using quit handlers to override the Quit command
• How to write a script server that can handle many different incoming events,
even over the network, and how to call it from another application or script
• How to use script properties to store persistent data
• Periodic actions and script agents (sorry, no bow-ties yet)
Theory of Operation
All Apple® Events sent to a script application are funneled through its script.
Every “on ” handler in the script intercepts a particular Apple event and its
parameters, and can do anything it wants to in response to that event.
The most basic use of this is to intercept the events that the System 7 Finder®
sends to an application when it’s launched. These events are “run” and “open”. (Their
internal codes are 'oapp' and 'odoc'.) These are described in the next two sections
“on run” Handlers
The run event is sent to an application when it is launched without any items to
open. This happens when the application is not already running, and:
• You double-click the application;
• The application is in the Apple Menu Items folder, and you choose it from the
Apple menu;
• The application is in the Startup Items folder, and you restart your Macintosh;
• or some third-party application or launcher utility (such as Magnet™ or
OnCue™) launches the script application.
(If the script application was already running when one of these actions occurs,
it will be brought to the front, but no events will be sent to it.)
If the script in the script application has an “on run” handler, the handler will
intercept the event, and the commands in that handler will run when the application is
launched. (If the script has statements that are not part of any handler - not enclosed
between “on ” and “end ”, in other words - those statements are an implicit run
handler. Thus a script with no handlers at all is really an “on run” handler.)
There is actually one thing that happens first: if the application is supposed to
display a startup screen (if “Never Show Startup Screen” was not checked when the