September 93 - OSL Scripting Components
OSL Scripting Components
Bo Klintberg
A Generic Scripting Architecture for Standalone and
Client/Server-based MacApp Applications.
Part 1: The Client Side.
If you're desperately seeking scripting and recording source code to incorporate into
your own MacApp programs, you might want to check out a new product called
Developer's C++ Source Code Library: OSL Scripting Components.
This product provides the developer with well over 100 carefully designed and
documented classes for scripting, recording, and Apple events communication. This
full-fledged library of extensible building blocks also helps you to implement other
related features such as the management of client and server applications in computer
networks. And all this without having to modify a single line of the original MacApp
3.0.x source code!
Using the classes in the OSL Scripting Components package will radically decrease the
time it takes to learn what Apple events really is all about. In fact, to guarantee you
the quickest possible learning curve, I designed a couple of classes that produces a
Sourcebug-like log window, so that you easily can monitor what's really happening
inside your application. The ScriptSender and ScriptServer demos (included in the OSL
Scripting Components package) both use log windows to let you see what's happening
(see Figure 1). Here's how the OSL Scripting Components can be used to communicate
with itself, both over the network (as seen here) and within the same application.
Since both the client and the server send and handle standard Apple events according to
the Required and the Core suites defined by Apple, they can communicate with any
other application that also uses the same protocol, for example the ScriptEditor shown
in Figure 2.
Note that the client's log window reports that the menu command has been handled and
that the Apple event is sent away to its server destination. A moment later the server
application's log window reports that it has handled the Apple event, resolved the
object specifiers and reached its final goal: for example to get the data we wanted. Then
the server sends back the result to the client, thus producing a new line in the client's
log window, confirming the result. The last action in a log window is always
autoscrolled and highlighted for maximum convenience.)
SENDING, RECEIVING, AND RECORDING
Scripting can be implemented in an application in a variety of ways. The three basic
mechanisms are sending, receiving and recording. All of these are supported by the
OSL Scripting Components package, which enables you to smoothly and easily attach
scripting functionality to your existing or up-coming product.
Script-sending Applications
Some of you might like to create client applications that send scripting Apple events to
server applications like FileMaker, Excel, Canvas, or the ScriptServer. With the OSL
Scripting Components source code in your hands, you can easily select a server
application and then send standard core suite events to it. Thus, you can mimic the
sending behavior of, for example, Apple Computer's Script Editor (previously called
Toy Surprise), or you could create a script-sending application named Updater that:
• Retrieves the data from all of John's currently open Excel documents;
• Processes that retrieved data inside your Updater application;
• Sends away the processed data to the "Results" FileMaker file on Anne's
Macintosh.
Script-receiving Applications
Some developers may like to create applications that can handle the receiving and
replying of standard suite scripting events. Such events could come from
script-sending applications like the ScriptEditor or the ScriptSender. A good
script-receiving application can handle requests from many clients simultaneously
(see Figure 2). Using the OSL Scripting Components package as a server, you can
receive and properly handle standard scripting Apple events from any other