 |
||||||||||||||
 |
 |
 |
 |
 |
 |
 |
||||||||
 |
 |
|||||||||||||
 |
 |
 |
 |
 |
 |
 |
||||||||
 |
||||||||||||||
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
Standalones for the Mac OS-challenged
5. Apple Events - the next step
As you have read in the documentation, an application can respond to Apple Events, which are messages sent by the Mac OS, either on its own behalf or on behalf of other applications. SuperCard projects and applications can cause Apple Events too, but we won't try to to unravel that here. An Apple Event is fed to your application by one particular message type, unsurprisingly called "appleevent". A handler for this message can get enough information to know what kind of event has occurred and where the event has come from. In fact, in the behaviour described in section 3 above, the "appleevent" messages are being generated by the OS, but they are all being processed by the SuperCard application engine. The "appleevent" handler is quite easy to write, and is described in the documentation. It takes the form:
SuperCard recognises five "core" Apple Events (these are the ones whose class is "aevt"). These are: "oapp" - the application has been opened directly (not via a document open) "odoc" - an "open" request has been given to a document "clos" - I haven't found a use for this event, which is related to an attempt to close a document from outside the application (?) "pdoc" - a request (typically from the Finder) to print a selected document (I have not found out how to select several documents for printing at one time and get the corresponding Apple Events to occur). "quit" - a request to quit the SA, either following a "pdoc" or as a result of a Shutdown by the user (or, in principle, a request from any other program). The key thing which isn't very clearly stated in the documentation is the order in which messages are sent: "appleevent" messages are **not** the first to be sent to an application when it opens. If an application is launched directly ("oapp") or by opening a document ("odoc"), the engine first opens the first card of the first window of the application (often an off-screen anchoring card), and then sends "startUp" and "openProject" messages to that card, and thence (if not handled there) to the project itself. Assuming that you have written handlers for both these messages, then only when the "openProject" handler closes is the "appleevent" message sent. This is a bit more complex than it first appears. What really seems to happen is that the "appleevent" message is sent as soon as the application gets into an idle state. Suppose we have a "startUp" handler that sets globals and parameters etc. If it does only this, it will close before the "appleevent" hits the fan. If on the other hand the "startUp" handler opens a modal window which invites the user to input some data, so that the project gets into an idle state waiting for input, then the "appleevent" message will occur **before** the end of the "startUp" handler. This can be embarrassing - it may sometimes be necessary to note that the event has taken place but to defer action until all the required initialisation has been done. When a document is opened, e.g. by double-clicking in the Finder, the application receives an "odoc" Apple Event message. Note that if the script of your SA is handling the "appleevent" messages, then the document **will not be opened** as a result of the "odoc" message unless your script opens it. This of course gives you the opportunity to examine the doc's Type code (using an appropriate XCFN) and to handle non-project docs appropriately (this is covered in the documentation). Note also that:
|
||
|
|
|