Standalones for the MacOS-challenged
a) Note that if your document is altered by your SA, or by user action allowed by the SA, then it will be saved automatically by the SCI (at unpredictable intervals) in its altered state. This means that you cannot implement the user-driven "Save" menu action used by classic Mac applications, and thus you cannot give the user the opportunity to decide not to save changes made to a document, without further intervention (see 6.1 below).
b) Note also that the implication of using a project as a document is that it will operate in its own window(s). If you wish to implement another feature of a classic Mac application - the inclusion of a toolbar, ruler etc in the same window as the document, then again you will have to employ a more elaborate scheme. This is covered briefly in 6.2 below.
c) The destruction of the original contents of the clipboard by script actions is inevitable for some types of SuperCard activity, even though the user may be unaware of what is going on - for example it is impossible to duplicate an object by scripting without invoking 'copy' and 'paste' commands, which by definition use the clipboard. This destruction can only be partly mitigated. It is possible (as explained in 6.3 below) to preserve PICT or TEXT data from the clipboard and to restore it later, but it is not possible to preserve and restore private data, since no SuperCard data type can handle it. This is an inherent limitation and all you can do is warn your user that it might happen. (I guess someone might like to write an XCMD pair - saveClip and restoreClip, say - but IFAIK there isn't one. [late note by Graham - Mark Lewis has written such a pair. They're a bit limited and rather slow, but they do help quite a bit.]
d) An attempt to print from the Finder is unlikely to produce the desired result.
e) Perhaps I should also add a note on scripting - if you have more than one project open, then you must be sure that you know which project is the current addressing focus, i.e. which one is "this" project. Otherwise familiar statements like
open window 3
might open window 3 of the wrong project. If you think this is going to get confusing (and it usually does) then you will have to make an explicit reference to the project you are talking about as in
open window 3 of project myApplicationProject
where "myApplication" project contains the name (or better, the whole path) of the intended project. A good way of doing this is to have a statement in your main project's startup handler of the form:
put value(word 2 of long name of this proj) into myApplicationProject
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