Standalones for the MacOS-challenged
As you have read in the ATI documentation, an SA can respond to Apple Events, which are messages sent by the MacOS, either on its own behalf or on behalf of other applications. SuperCard projects and SAs can **cause** Apple Events too, but I am not going to unravel that here.
An Apple Event is fed to your SA 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 SCI.
The "appleevent" handler is quite easy to write, and is described in the ATI documentation. It takes the form:
on appleevent eclass,eID,sender request appleevent data put it into temp
-- if a file has been double-clicked this will be the file
-- stuff for verifying, identifying and processing the events end appleEvent
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 SA when it opens.
If an application is launched directly ("oapp") or by opening a document ("odoc"), the SCI first opens the first card of the first window of the SA (usually an off-screen Anchor 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 SA 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 SA 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 ATI documentation).
Note also that:
a) If the doc is a project, and your SA does open it, then an additional "openProject" message is sent to the SA via the document (unless handled within the doc itself).
b) An attempt to open a doc which is already open will still result in an "odoc" Apple Event being sent to your SA. It's up to you to notice that the document is already open and react accordingly.
2. What an SA needs to do to be a good MacOS citizen
3. What you can get away with without doing any special scripting
4. Limitations of the 'non-interventionist' approach
5. Features of the classic app which need scripting help