Standalones for the MacOS-challenged

4. Obvious Limitations

a) Note that if your document is altered by your application, or by user action allowed by the application, then it will be saved automatically by the engine (at intervals, particularly when card switches occur) in its altered state. This means that you cannot easily 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 taking further intervention behind the scenes (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 regular 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 currently impossible to duplicate an object by script 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, custom data from some other application, since SuperCard data types probably won't handle it.

d) A Mac OS 9 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 currently 'in focus', meaning 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

1. BNDLs, icons and binding

2. What an application needs to do to be a good Mac OS citizen

3. What you can get away with without doing any special scripting

4. Limitations of the 'non-interventionist' approach

5. Features of a regular application which need scripting help

6. A sketch map of some workarounds