Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!crackers!m2c!umvlsi!dime!dime.cs.umass.edu!nayeri From: nayeri@cs.umass.edu (Farshad Nayeri) Newsgroups: comp.sys.mac.hypercard Subject: Re: Trapping out Command-Period key presses. Message-ID: Date: 18 Sep 90 06:38:26 GMT References: <10190@goofy.Apple.COM> <44774@apple.Apple.COM> <11983@chaph.usc.edu> Sender: news@dime.cs.umass.edu Reply-To: nayeri@cs.umass.edu Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst) Lines: 81 In-reply-to: talcott@nunki.usc.edu's message of 16 Sep 90 03:40:50 GMT I asked the original question about the abort message and left town for a couple of days and now that I am back I realized that some of the messages are purged at my site. Does anyone have the messages about this issue (command - period) backed up? Can anyone tell me where I can get the archives for this newsgroup? Is there one anyway? Back to the abort discussion... In article <11983@chaph.usc.edu> talcott@nunki.usc.edu (Adam Talcott) writes: The user would press the command-period key combination and HC would do the following: a) if the current instruction is not complete, finish the operation b) remember which script and the location in that script that was about to be executed and generate an "abort" message c) in the abort message handler, the user can verify whether or not they actually wish to cancel the current operation or continue. If the user wishes to continue, execute a new HyperTalk command that would return to the location stored in part b). Otherwist just exit IMHO, this would be a good feature to add to HC... I am not sure if it is so good to give the programmer ability to continue after an abort has taken place through a new language construct. My original thought was that an "abort" message would be sent and the current script would be terminated. The abort handler can send messages if it needs to. The other approach would be to let the process continue after abort handler is done (something like the openCard handler) and if the handler wants to abort literally, it can use the exit statement. One of these is probably easier to implement (I would think the second one, right Steve?) Another issue to consider is the performace degredation of doing it this way, once again, since I don't know much about Hypercard internals, I will mot make a comment to make a fool of myself. Also bill coderre writes: Lee Spector: |I think there IS a good way to deal with aborts that preserves |interruptability and also assures that important "cleanup" code always |gets executed. As a LISP hacker I've become very fond of LISP's |UNWIND-PROTECT special form. Yup, that's a terrific way to cope with interruptibility and provides a really clean language form to do it. But isn't that asking an awful lot to add it to Hypertalk? There's nothing at all in HT either conceptually or structurally similar, and since there is no such thing as "interrupts" either, there's no real foundation for such a feature. I'd much rather add about a hundred other things to Hypertalk before that. I agree with you about the fact that interrupts (or exceptions if you are talking software) are quite different conceptually. I think the cantAbort is a particularly nasty way to handle them though. I haven't seen hypercardd 2.0 (standard cries about it not being available thru ftp...), and I am sure there are other features that are needed more than this one. In terms of explaining to the programmer, we don't need to get in details about the philosophical aspects of exceptions, just tell them something like: pressiong command-period while a script is running is like putting a statement "send abort to the target" [Or is it "me"?] in the script. In terms of it not going with the standard messages in hypercard, what about the "idle",, "mouseWithin" and "mouseLeave" events that are diffenent than others? (idle happens when nothing is going on, and mouseWithin/Leave happens without any mouse button activity. Having the idle handler do the cleanup is the same as having an exception handler, it is just much less direct and safe. Allegro CL is available for Macintosh and runs like a champ, although it too lacks an application generator. (wry grin) So are a couple of versions of Smalltalk that do have application generators as far as I know. The problem is that if you are writing software for the educational (highschool/college) environments, you can hardly count on their having platform to run Allegro CL, or Smalltalk (even if the applications are standalone, they can be very memory intensive, right?) --farshad -- Farshad Nayeri Object Oriented Systems Group nayeri@cs.umass.edu Dept. of Computer and Information Science (413)545-0256 University of Massachusetts at Amherst