Chapter 22. Unscriptable Applications

Some applications are not scriptable; they have no repertory of Apple events to which they are prepared to respond. The developers simply omitted this feature, like the tinsmith who forgot to give the Woodsman a heart. You try to open the application's dictionary and you get an error. Other applications are scriptable, but they aren't scriptable in the way you'd like; the thing you'd like to make the application do isn't among its scriptable behaviors. In a case like this, how can you script the unscriptable?

On Mac OS 9 and before, the answer was to use a macro program. A macro program has the power to "see" an application's interface and to act as a kind of ghost user, pressing buttons, typing keys, and choosing menu items. Anything a user can do in an application can presumably be performed through some definable sequence of mouse and keyboard gestures; therefore it might be possible to emulate that sequence of gestures with a macro program. The result might not be as fast, elegant, or flexible as using AppleScript, but it could get the job done; plus, a macro program might itself be scriptable. (Three very strong macro programs that I often used on earlier System versions were QuicKeys, PreFab Player, and OneClick; see http://www.cesoft.com/products/qkmac.html, http://www.prefab.com/player.html, and http://www.westcodesoft.com/index.html.)

In the past, macro programs depended upon a feature of the System architecture whereby third-party code fragments called system extensions (or INITs) could be loaded into the System at startup in such a way as to modify the System's response to Toolbox calls. In essence, when the System was told to do a certain thing by any program (including itself), this code fragment would be called instead; usually it would also call the System's original functionality, so as not to break the computer altogether, but along the way it would interpose functionality of its own. (For a fine discussion of INITs, see Joe Zobkiw, A Fragment of Your Imagination [Addison-Wesley], Chapter 4.)

The trouble with this approach was that INITs were a threat to stability and reliability. They caused no end of headaches for users, who often found different INITs conflicted with one another, and for application developers, who would learn that their application misbehaved in the presence of some INIT. The ability of users to customize their own systems meant that every user's system could be essentially different from every other's.

On Mac OS X, INITs are abolished. In fact, that's part of the point of Mac OS X: at bottom, every system should be a clean system, and all machines should reliably work the same way. But without INITs, there's no way for a macro program to hook into the System's functionality at a level low enough for it to do the things that a macro program needs to do. This, in the early days of Mac OS X, made scripting the unscriptable next to impossible.

Recently, a solution to this quandary has emerged from Apple itself. As part of an effort to make Mac OS X accessible to people who may not be able to use a mouse and keyboard or see a computer screen, Apple has created the Accessibility API, a set of Toolbox commands that can do just what a macro program would do—"see" an application's interface and manipulate it like a ghost user wielding an invisible mouse and keyboard. Going even further, they have made the Accessibility API itself scriptable via AppleScript. Thus, you may be able to use AppleScript to drive the Accessibility API to manipulate the interface of a program that is not itself scriptable, or not scriptable in the way you desire. This technique is called GUI scripting.