AppleScript_ The Definitive Guide - Matt Neuburg [240]
Results window
I name this window results. I want to know when the user tries to close this window, so I check Window: should close (a delegation query).
Results window: the table view
I want to know when the user double-clicks a row of the table view, so I select Action: double clicked.
This completes our use of Interface Builder, so we save our work and switch to Xcode. Find the SearchTidBITS.applescript file in the Xcode project window and open it. Templates for the event handlers that we specified in Interface Builder have already been created:
on will open theObject
(*Add your script here.*)
end will open
on launched theObject
(*Add your script here.*)
end launched
on choose menu item theObject
(*Add your script here.*)
end choose menu item
on clicked theObject
(*Add your script here.*)
end clicked
on double clicked theObject
(*Add your script here.*)
end double clicked
on should close theObject
(*Add your script here.*)
end should close
Now we'll write our script's code, filling in these event handlers and adding any further user handlers of our own. Let's tour the final code a little at a time. In Example 27-1 we declare some top-level globals. We also write code for the launched handler that will be called right after the application has started up; this is the best place for general initializations, which is just what we use it for here, locating the Perl file within our application's bundle and retaining its POSIX pathname as a global.
Example 27-1. Globals and launched handler
global perlScriptPath, L1, L2, textSought, titleSought, authorSought
on launched theObject
local f
set f to (path to resource "parseHTML.pl")
set perlScriptPath to quoted form of (POSIX path of f)
end launched
Example 27-2 shows the will open handler. Observe that these event handlers have a parameter, theObject; this contains a reference to the interface element with which this action message, notification, or delegation query is associated. In this case, we know that only the Search window is set to deliver a will open notification, so there is no need to bother checking theObject's identity; we just blithely assume that it's the Search window.
Example 27-2. The will open handler
on will open theObject
tell theObject
call method "setDisplayedWhenStopped:" of progress indicator 1 with parameter 0
end tell
end will open
The code illustrates the use of call method to form a manual bridge from AppleScript to Objective-C. We want to make sure that the progress indicator is invisible when not spinning. This setting is available through a built-in Cocoa method, but no AppleScript property is bridged to it, so we cross the bridge ourselves; in effect, we form the equivalent of the following line of Objective-C code:
[theProgressIndicator setDisplayedWhenStopped: NO];
Example 27-3 shows the choose menu item event handler, which is the action message from the Search → New menu item. We hide the Results window and show the Search window, emptying the form cells and selecting the first cell, ready for the user to enter text. Once again, AppleScript is not bridged to a built-in Cocoa method that we want to call, so we use the call method command to call it directly.
Example 27-3. The choose menu item handler
on choose menu item theObject
hide window "results"
tell window "search"
tell matrix 1
set content of cell 1 to ""
set content of cell 2 to ""
set content of cell 3 to ""
call method "selectTextAtIndex:" of it with parameter 0
end tell
show
end tell
end choose menu item
Example 27-4 shows the clicked handler. This is the Search button's action message, and is the heart of our application. To make the code clearer, I've broken the functionality out into some ancillary user handlers. We start by initializing our globals based on what's in the Search window form; then, after a sanity check, we call the next user handler, doTheSearch.
Example 27-4. The clicked handler and an associated utility
on clicked theObject
tell matrix