Section 2.2. Internally Scriptable Application

2.2. Internally Scriptable Application

Some applications implement automation not through AppleScript but by means of some other language (possibly one unique to that application) that effectively operates entirely within that application. Such an application is internally scriptable . But even though such an application does not use AppleScript for its internal scripting, the developers might still wish it to be able to communicate with other applications. That means Apple events, and AppleScript is a convenient way (convenient both for the developers and for the end user) to construct and send Apple events. The internal scripting language can most likely operate on text, so a typical approach is to give

Figure 2-3. Script Debugger in action

Figure 2-4. Explorer view in Script Debugger

it the ability to treat text as AppleScript code (by compiling and running it). Even though you can use AppleScript code in an internally scriptable application, you wouldn't want to develop it there, as there is no provision for editing and testing your code, displaying a target application's dictionary, and so forth. Thus you'll usually develop your code in a script editor application and then copy it into the internally scriptable application.

A good example is the database application FileMaker Pro . It has an internal scripting language that can execute text as AppleScript. This text can be static or constructed dynamically ("calculated"). Figure 2-5 shows a case in point, with FileMaker Pro being used to communicate via AppleScript with Apple's Mail program. The idea is that you might like to store your contacts in a true database program, but then you might like to create and send an email message to one of them in a true email client (see "Combining Specialties" in Chapter 1). Thus, the FileMaker window (in front) displays a database of contacts; pressing the "To" button causes Mail to create a new email message (in back) using the email address from the current FileMaker record.

Figure 2-5. FileMaker talking to Mail

The FileMaker script triggered by pressing the "To" button consists of a single step, telling FileMaker to treat a piece of calculated text as AppleScript (entered by way of FileMaker's usual annoying cascade of modal dialogs, as shown in Figure 2-6):

 "set theAddress to \"" & fm address book::email & "\" tell application \"Mail\"     tell (make new outgoing message)         set visible to true         make new to recipient at end of to recipients 
¶             with properties {address:theAddress}     end tell end tell"

Figure 2-6. Specifying a calculated AppleScript step in a FileMaker script

The code is particularly ugly (and difficult to write), because it isn't AppleScript: it's the instructions, in FileMaker's internal calculation language, for constructing a string that will be treated as AppleScript. This string consists of three piecestwo literal strings, surrounded by quotation marks, and a reference to the current record's email field. The three strings are joined by FileMaker's concatenation operator (&, just as in AppleScript). But the constructed string must itself include quotation marks around the contents of the email field and around the name of the Mail application; to indicate these within a string literal, they have to be "escaped" by preceding them with a backward slash (\). This accounts for the rather bizarre appearance of the first and second lines of the code. But cheer up: things could be worse. At least FileMaker permits return characters within a string literal, so the code can be laid out in lines that reflect how the real AppleScript code would look. (The trick in the fifth line, allowing a line of AppleScript code to wrap in the middle by following AppleScript's line-continuation character with FileMaker's carriage-return character, is so bizarre that I won't even try to explain it.)

Another internally scriptable application is Radio UserLand , the inexpensive "little brother" of UserLand Frontier (for our purposes the two programs are essentially identical). It's a multipurpose scripting program, typically used for creating web pages and for maintaining blogs. It stores scripts internally, and executes them; these scripts are usually in UserLand's own scripting language, UserTalk , but alternatively they can be written in AppleScript.

Figure 2-7 shows some AppleScript code being run in Radio UserLand. The AppleScript code is in the middle windowthe one whose language popup, at the bottom of the window, is set to "AppleScript." (You should ignore the triangles at the left of each line, which are a feature of Frontier's outline-based script editing environment.) The UserTalk code in the bottom window calls the AppleScript code in the middle window and displays the result in the top window.

Figure 2-7. Radio UserLand