Standalones for the MacOS-challenged
By this I mean, if you let the SCI do all the work and don't script any handling of Apple Events etc., what is the extent of your SA's behaviour?
The situation appears to be:
3.1 If your SA doesn't handle documents, i.e. is only required to launch and quit, then the SCI will do all the work for you apart from the maintenance of the clipboard, i.e.
a) Your SA will be launched by double-click from the Finder etc, and will be sent a "startUp" message followed by an "openProject" message.
b) If you put a "Quit" button and/or menu in your project which carries out the right actions ("close all windows" for SC2.5.2 and earlier, "close project" for SC3.0), then the project will quit in good order.
c) If your SA is required to quit as a result of the user shutting down the Mac, then the SCI will take care of it and quit your project after sending the various close messages ("closeCard" "closeWindow" and "closeProject" are sent in SC 2.x and SC3.x, and additionally in SC3.x, "quitSuperCard" is sent before the final "closeCard").
d) If your SA has used the clipboard, then the original contents will be destroyed and cannot be recovered. The SCI does not help with this problem.
3.2 If your SA handles documents, and these are well-formed SuperCard projects, then the SCI will do quite a lot for you. If you have other types of documents (TEXT, PICT, etc.) then this requires more handling as described in 5.x below.
When I refer to a document being 'a SuperCard project', this means that the project will be in every respect an SC project except that its T/C pair will have been altered to correspond to the Creator code of your SA and to a Type code which you have chosen. Note that the SCI doesn't look at the T/C code to determine if a file is an SC project - if asked to open such a file, the SCI will automatically go into its "Open Project" routine, and if it turns out that the doc isn't a project, the SCI will crash (or at any rate give an error message).
This is what happens:
a) Your SA will be launched by double-click from the Finder etc, and will be sent a "startUp" message followed by an "openProject" message. In this scenario no additional project (document) will be opened unless you have organised this yourself, either via a "File" "Open" menu or as a scripted action when the project starts.
b) If a user double-clicks on a document (project), or drops its icon onto the icon of your SA, then the Finder will look to see if your SA is running and if it isn't running it will launch it.
If the SA was not running, the SCI within your SA will open the first card of its first window. It will then send the SA a "startUp" message followed by an "openProject" message. If the SA is already running, then the "startUp" message will be omitted. Either way, the SCI will then open the document (which, as we have already said, is in fact a SuperCard project), open the first card of its first window, and send it an "openProject" message. The doc, being the last opened, will be the owner of the top window. If your doc doesn't have any handlers in it (quite a usual situation), your SA receives a second "openProject" message, the one originally sent to your doc - this is because your SA is in the same place in the message-passing hierarchy as the SharedFile was while you were running under SuperCard. Note the 'shoot first and ask questions afterwards' behaviour of the SCI in opening your document for you before you are told about it.
c) If the user double-clicks on a second or subsequent document, the (b) sequence occurs, the SA of course being already running. The new doc is opened by the SCI and if no script action occurs, it now occupies the top window. This sequence can be repeated indefinitely. Any confusion resulting in the opening of multiple documents is your problem. There is no general way of handling this, since the things that applications do with documents are so varied, but obviously you can use the fact that there is only one "startUp" message to initialise a global that counts and identifies the opened docs via the "openProject" messages. By careful handling of these, and/or design of your SA so it doesn't mind how many documents it has open, you may still be able to avoid dealing with the underlying Apple Events.
d) The quit information given in 3.1 (b) is still valid, except that in SC3.x, it is now your responsibility to make sure that all projects are closed. You can do this by issuing a "quit SuperCard" command, which will close all projects.
e) An attempt to print one of your docs from the Finder by selecting its icon and invoking "Print" from the Finder's "File" menu always results in the current card of the top window being printed. If the SA was not running, then the Finder launches your SA, but not the selected document and prints the top window which inevitably belongs to the SA itself. The Finder then forces the SA to quit.
If the SA was already running, then again the top window is printed, but this may be the window of a previously opened document. The important thing to note is that the document selected in the Finder is not specially opened as a result of "Print" request.
In both cases the Page Setup and Print dialogs are shown, and the card is printed at the top left of the page.
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