 |
||||||||||||||
 |
 |
 |
 |
 |
 |
 |
||||||||
 |
 |
|||||||||||||
 |
 |
 |
 |
 |
 |
 |
||||||||
 |
||||||||||||||
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
Standalones for the Mac OS-challenged
6. A sketch map of some workarounds
The following is just some stuff that some people do while developing projects. We make no claim as to any of these ideas being the best way to deal with the problem they tackle, but they should help.
6.1 Conventional "File" menu behaviour for documents which are projects There is a lot to be said for arranging things so that the documents of your application 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 your standard SuperCard development software itself. The bad news is that the SuperCard engine will save your documents when it feels like it. This is not what users of regular applications have come to expect. The standard behaviour, on the Mac and in Windows, is that the user creates or opens a document, edits it, and then saves it or discards it entirely according to their wishes. To fix this in in your application, you could do the following: For every document 'opened' by your user, make a copy using an appropriate external, give it a new Type code, also with a suitable external (for example SetFileInfo). This code will represent a temporary document to your application. You then let the user manipulate the temp document When the user saves, quits, and so on, 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 application at all. Don't forget to delete your temp document on quitting, and to look for an existing copy of your temp document when you restart (in case the Mac 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' document to be presented when your application opens or when "New" is chosen from the "File" menu, you can have a proforma document, probably with another Type code, hanging around on the disk with your application. In fact this can double as a Preferences doc (keep it in the appropriate place), since it can be used to contain all your application's default settings. If you allow the user to change these, then you could use 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. To counter this your Apple Event handler has to repel these potential boarders to your application by looking at their Type codes and refusing to open them.
6.2 Conventional "Doc with tools" appearance A lot of regular applications 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 disadvantages, such as not being guaranteed to stay on the same level as your main doc window, not allowing easy drag and drop of items into the document, 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 and so on. 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 and more are maintained as the user moves the mouse around. Such scripting is generally only appropriate to your application 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 document's 'window' has to be copied to its place in the window inside your application, and to be copied out again when any significant change is made. So now we're into:
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 external 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 application 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 application 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 application will be recovered. On the other hand, this means that you may have to invoke a full-scale version of saveClip repeatedly as your application 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 applications are being run together with your software. Of course, if your application 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 application. You will need this on quitting anyway. Ends
|
||
|
|
|