Standalones for the MacOS-challenged
The following is just some stuff that I have had to do while developing my projects. I make no claim as to any of these ideas being the best way to deal with the problem they tackle, but it may help you a bit.
6.1 Conventional "File" menu behaviour for docs which are projects
There is a lot to be said for arranging things so that the docs of your SA are SuperCard projects. Firstly, you get a hell of a lot of structure 'for free' - fields, graphics, windows, even (though I don't recommend it) scripts. Secondly, you can examine and edit them at the development stage with ATI's very powerful tools.
The bad news is that the SCI will save your docs when it feels like it. This is not what users of classic apps have come to expect. The classic behaviour, on Mac and Windows, is that the user creates or opens a doc, edits it, and then saves it or discards it entirely according to his/her wishes. To fix this in in your SA, you could do the following:
For every document 'opened' by your user, make a copy using an appropriate XCFN, give it a new Type code, also with a suitable XCFN (ATI provides SetFileInfo). This code will represent a temporary doc to your application. You then let the user manipulate the temp doc. When the user saves, quits, etc., copy the temp doc over the top of the actual doc and alter the Type code back to your main doc type. So the actual doc is never opened in your SA at all. Don't forget to delete your temp doc on quitting, and to look for an existing copy of your temp doc when you restart (in case the machine crashed) so as to eliminate it before starting a new temp doc. This may be a bit more tricky if you allow several docs to be open at once.
In this scheme, to allow a new 'untitled' doc to be presented when your SA opens or when "New" is chosen from the "File" menu, you can have a proforma doc, probably with another Type code, hanging around on the disk with your SA. In fact this can double as a Preferences doc (keep it in the System folder), since it can be used to contain all default settings - if you allow the user to change these, then you need a secret copy of your original proforma to allow the user to revert to the original settings.
BTW, if you have these other doc types which are not 'real' documents, the user may well switch back to the Finder in the middle of using your SA and do a sneaky double-click on one of them. So your Apple Event handler has to repel these potential boarders to the good ship SA by looking at their Type codes and refusing to open them.
6.2 Conventional "Doc with tools" appearance
A lot of classic apps feature a document which appears in a window which also contains items like a toolbar and a ruler. SuperCard doesn't help you with this - the SuperCard idea of a toolbar is a palette window, but this can have severed disadvantages, such as not being guaranteed to stay on the same level as your main doc window, not allowing drag and drop of symbols etc onto the doc, and not allowing the user to move from toolbar to doc and back without additional mouse clicks.
The only way I know how to deal with this is to show the doc in a suitable object (a field for text, a graphic for graphics) **within** a window which also contains a toolbar etc. This means putting in a lot of scripting to ensure that the various boundaries within the window, between the toolbar, the doc, various border areas etc, are maintained as the user moves the mouse around. Such scripting is IMHO only appropriate to your SA and not to a mere document.
Unfortunately this in turn means that the scheme of 6.1 above has to be further complicated, in that when a doc is Opened, the doc's 'window' has to be copied to its place in the window inside your SA, and to be copied out again when any significant change is made. So now we're into:
doc --> temp doc --> 'inside SA' copy of main window of doc
and vice versa, to preserve our Saving scheme. You might think you can 'cut out the middle man' and not have the temp doc, but unfortunately this only works if your doc really consists of one card in one window, which is often not the case.
6.3 Clipboard maintenance
The ClipInfo XCFN function in the SuperCard Xtend project allows you to find out if the clipboard contains PICT, TEXT, or other ('Private') data. So you when your SA makes 'invisible' use of the clipboard, for example to duplicate an object, then you can invoke a 'saveClip' handler which puts either kind of recognisable data into an appropriate object which acts as a buffer (perhaps on a card in an off-screen 'Anchor' window). Then when your SA has finished footling with the clipboard, it can invoke a 'restoreClip' handler that takes the stuff out again (if you use 'cut' and 'compact', then the space used up in your SA will be recovered - on the other hand, this means that you may have to invoke a full-scale version of saveClip repeatedly as your SA proceeds, so this is probably not such a good idea). Of course you could get into space problems doing this - clipInfo will tell you how big the clipBoard is, so you could implement a scheme which refuses to store a clipboard larger than a certain size.
Sadly, you can do nothing to preserve the 'private' data by scripting, since by definition you will not have a suitable object to store it in. If it gets destroyed, it gets destroyed. The best you can do is to empty the clipboard so that the user at least doesn't get unexpected junk to paste in whatever other app is being run together with your SA.
Of course, if your SA has "Cut" and "Copy" items in an "Edit" menu, then you are allowing publicly available use of the clipboard. If the user invokes one of these items, then you need to run a 'purgeClip' handler which tells your SA that there is nothing to restore - of course it empties your buffer and compacts your SA. You will need this on quitting anyway.
Ends
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
6. A sketch map of some workarounds