AppleScript_ The Definitive Guide - Matt Neuburg [236]
Let me explain in a bit more technical depth how AppleScript Studio exposes Cocoa to the AppleScript programmer. You'll need a sense of this in order to use AppleScript Studio effectively in any case. Cocoa is an application framework, so it operates through messages that travel back and forth between its code (the code inside the framework) and your code (the code that you actually write, whether you're writing in Objective-C, AppleScript, or whatever). Cocoa is like a gigantic lock, and your code must be structured as a key that fits that lock; you have to write code that will slot into Cocoa's expectations of how an application should work. Thus, even though you can't see inside Cocoa, you do need to know what messages to send to Cocoa and what messages Cocoa will send you, so that its code and your code can work together properly. These messages come under some basic headings:
Built-in methods
The interface elements, such as windows and menus and buttons and text fields, as well as the application as a whole, are prepared to respond to certain messages that you can send. For example, you might like to tell a button to change its title, or ask a text field what the user has typed in it, or tell a window to close, or ask the application whether it is frontmost. You can do these things because the entity to whom you're speaking defines an appropriate message. A button "knows" how to change its title and defines a way for you to tell it to do so; a text field "knows" how to report what the user has typed in it; and so forth. These predefined messages that you can send are the built-in methods .
Action messages
Certain interface elements have a single special behavior when the user performs a certain special operation on them. In the case of a button, that operation is pushing the button. In the case of a text field, it's typing Return within the text field. This is the interface element's action, and when the action occurs, your code can receive an action message so that it can respond.
Lifetime notifications
Cocoa will, if you wish, notify your code of things that routinely take place over the lifetime of an application. For example, you might like your code to be called when your application first starts up, when it comes to the front, or when it is about to quit; or you might like to be informed when the user selects a line in a table or types a character in a text field. These are the lifetime notifications , and again, they exist so that your code has a chance to respond to what's happening.
Delegation queries
Cocoa will sometimes offer your code the opportunity to intervene in its behavior. For example, suppose that the user clicks the mouse to select a line in a table. Normally that line would just be selected, but perhaps your code might have some reason for making it unselectable at that moment. Cocoa can delegate the responsibility for this sort of decision to your code, querying your code as to whether it should proceed normally; if you elect to receive such delegation queries , your code must give a definite answer as to how Cocoa should proceed.
Thus there are two kinds of messages in Cocoa—those you send to Cocoa (the built-in methods) and those that Cocoa will send to you (the action messages , lifetime notifications, and delegation queries). Furthermore, your code is essentially idle until something triggers some part of it. An application does nothing unless it is somehow told to do it. And the only way your code can be told to do anything is through a message that Cocoa sends it. In other words, all your code will run only in response to action messages, lifetime notifications, and delegations queries; so your code must be structured, not independently, but as responses to messages from Cocoa.
The architecture I've just described does not perfectly match how AppleScript code works. So to make it match, the Apple folks have interposed a kind