|
Standalones for the Mac OS-challenged
3. How much can you get away with?
By this I mean, if you let the SuperCard application engine do all the work and don't script any handling of Apple Events etc., what is the extent of your application's behaviour?
The situation appears to be:
3.1 If your application doesn't handle documents, i.e. is only required to launch and quit, then the SuperCard engine will do all the work for you apart from the maintenance of the clipboard.
a) Your application 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 ('quit SuperCard' or 'close all windows'), then the project will quit in good order. c) If your application is required to quit as a result of the user shutting down the Mac, then the application engine will take care of it and quit your project after sending the various close messages. d) If your application has used the clipboard, with or without direct user instructions, then the original contents have been replaced with whatever your application copied.
3.2 If your application handles documents, and these are well-formed SuperCard projects, then the engine 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 a SuperCard project - except that its T/C pair will have been altered to correspond to the Creator code of your application and to a Type code which you have chosen. Note that the engine doesn't look at the T/C code to determine if a file is a real 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 application will probably give some form of error message.
This is what happens:
a) Your application will be launched by double-click from the Finder, 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 application icon, then the Finder will look to see if your application is running - if it isn't then it will launch it. If the application was not running, the engine within your application will open the first card of its first window. It will then send the application a "startUp" message followed by an "openProject" message. If the application is already running, then the "startUp" message will be omitted. Either way, the engine 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 document, being the last opened, will be the "owner" of the top window. If your document doesn't have any handlers in it (quite a normal situation for document-style projects), your application receives a second "openProject" message, the one originally sent to your document. This is because your application is in the same place in the message-passing hierarchy as the SharedFile was while you were running within the normal SuperCard development environment. Note the 'shoot first and ask questions afterwards' behaviour of the engine 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 application of course being already running. The new document is opened by the engine 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 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) In Mac OS 9 and earlier, 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 application was not running, then the Finder launches it, but not the selected document and prints the top window which inevitably belongs to the application itself. The Finder then tells the application to quit. If the application 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 specifically 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. None of this applies in Mac OS X, as Finder printing is not provided.
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 the standard application which need scripting help 6. A sketch map of some workarounds |
