bjornl@milton.u.washington.edu (Bjorn Levidow) (09/13/90)
Does anybody know how to trap out Command-Period key presses by the users? I have a stack where I want the user to do more than browse, so I can't have the stack locked, but I don't want them to be able to interrupt a script in the middle of execution. Putting a trap in an idle handler could be done, but it would be cumbersome in my situation. Any elegant solutions? Thanks in advance. =============================================================================== \ Bjorn Levidow | Romance is unreal...it's the essence / \ Dept. of Psychology | of life, but not the reality of it. / \ University of Washington | ---Robyn Hitchcock / \ Seattle, WA 98195 | It's mine! All mine! / \ bjornl@u.washington.edu | I'm independently thoughtful! / ===============================================================================
stm@apple.com (Steve Maller) (09/13/90)
In article <7433@milton.u.washington.edu> bjornl@milton.u.washington.edu (Bjorn Levidow) writes: > Does anybody know how to trap out Command-Period key presses by the users? HyperCard 2.0 has a new property called "cantAbort". It prevents Command-Period from doing anything. However, note that this is VERY dangerous, because causing a script to be un-stoppable could force a user to reboot his machine if the script runs away from itself. This can easily destroy a stack! Steve Maller HyperCard Engineering Team Apple Computer
nayeri@cs.umass.edu (Farshad Nayeri) (09/13/90)
In article <7433@milton.u.washington.edu> bjornl@milton.u.washington.edu (Bjorn Levidow) writes: Does anybody know how to trap out Command-Period key presses by the users? I have a stack where I want the user to do more than browse, so I can't have the stack locked, but I don't want them to be able to interrupt a script in the middle of execution. Putting a trap in an idle handler could be done, but it would be cumbersome in my situation. Any elegant solutions? Thanks in advance. I don't think there is anyway to do this directly from Hypertalk. I do have a workaround that is not very elegant IMHO, but gets the job done using only Hypertalk. I found out that usually cancelations involved breaking out of a loop, so I wrote the following workaround: -- notice the code is written on the fly -- syntax might be wrong, but the idea is there put the msg into msgBack -- ATP: what is the right way to use the message box anyway? on viewAllCards repeat for i = 1 to number of cds if the mouse is down then exit repeat -- also you can call handler put "visiting card"&&i&". [Hold mouse button down to cancel.]" go to cd i end repeat end viewAllCards put msgBack hide msg It works. I am not sure if the ATP would approve it though (I kind of doubt it...) A better way is to use a non-modal dialog box (I originally thought ShowDialog XCMD stack includes non-modal dialogs, but as far as I can see it doesn't [Jay Hodgden, are you there?]) with Cancel button on it. Kind of like the way the old Print... command use to work on System version 4.0-. As far as command-period discussion goes, I am not sure if it is even wise to tell the novice user about command-period. That way they can break out of very important scripts while they are running (for example openCard, etc...) and weird things may happen to them. Note to people who have seen 2.0: is this problem fixed? -- Farshad Nayeri Object Oriented Systems Group nayeri@cs.umass.edu Dept. of Computer and Information Science (413)545-0256 University of Massachusetts at Amherst
jon@gara.une.oz.au (Jonathan Burne CCEN) (09/13/90)
In article <10190@goofy.Apple.COM>, stm@apple.com (Steve Maller) writes: > > HyperCard 2.0 has a new property called "cantAbort". It prevents > Command-Period from doing anything. However, note that this is VERY > dangerous, because causing a script to be un-stoppable could force a user > to reboot his machine if the script runs away from itself. This can easily > destroy a stack! > Been there, done that! Be warned, this new HyperCard is pretty powerful stuff, should it come with some sort of warning; "Do Not Open This Script When Young Children Are Present" :-) Jonathan Burne Macintosh Support Computer Centre University of New England Armidale 2351 AUSTRALIA
nayeri@cs.umass.edu (Farshad Nayeri) (09/13/90)
In article <10190@goofy.Apple.COM> stm@apple.com (Steve Maller) writes: In article <7433@milton.u.washington.edu> bjornl@milton.u.washington.edu (Bjorn Levidow) writes: > Does anybody know how to trap out Command-Period key presses by the users? HyperCard 2.0 has a new property called "cantAbort". It prevents Command-Period from doing anything. However, note that this is VERY dangerous, because causing a script to be un-stoppable could force a user to reboot his machine if the script runs away from itself. This can easily destroy a stack! Steve, why can't command-period be an event and generate a message just like anything else? So that you can specify a handler in the hierarchy? It seems to make a lot of sense to me. So programmer can specify a handler like: on abort -- or commandPeriod or whatever you want to call it answer "Don't you touch that key combination again!" doMenu "Quit Hypercard" end abort Of course, the cantAbort property should be true for this handler. This would also be nice because if the programmer finds an abort condition, they could just do abort. on checkAllNamedCards if bg fld "name" of this cd is empty then abort else put bg fld "name" end checkAllNamedCards I think this would be much nicer to use. Any reactions? --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
stadler@Apple.COM (Andy Stadler) (09/13/90)
In article <NAYERI.90Sep13093555@ibis.cs.umass.edu> nayeri@cs.umass.edu writes: >In article <10190@goofy.Apple.COM> stm@apple.com (Steve Maller) writes: > > HyperCard 2.0 has a new property called "cantAbort". It prevents > Command-Period from doing anything. However, note that this is VERY > dangerous, because causing a script to be un-stoppable could force a user > to reboot his machine if the script runs away from itself. This can easily > destroy a stack! > >Steve, why can't command-period be an event and generate a message just like >anything else? So that you can specify a handler in the hierarchy? It seems to >make a lot of sense to me. So programmer can specify a handler like: > Sending "abort" messages wouldn't be very useful, because the only time you could receive such a message is during idling - during which cmd-period doesn't really do anything anyway. Command period is dangerous when it is pressed in the middle of a long script or during some long operation. By the time you received the "abort" message the long operation will have long since completed and it won't really be able to do any good. --Andy stadler@apple.com
spector@brillig.cs.umd.edu (Lee Spector) (09/14/90)
In article <44774@apple.Apple.COM> stadler@Apple.COM (Andy Stadler) writes: >... nayeri@cs.umass.edu writes: >>Steve, why can't command-period be an event and generate a message just like >>anything else? > >Sending "abort" messages wouldn't be very useful, because the only time you >could receive such a message is during idling -during which cmd-period doesn't >really do anything anyway. > >Command period is dangerous when it is pressed in the middle of a long script >or during some long operation. By the time you received the "abort" message >the long operation will have long since completed and it won't really be able >to do any good. > >--Andy stadler@apple.com 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. Unwind-protect takes a bunch of code to be executed (the "protected form" in lisp lingo) and some "cleanup" code (actually, any number of "cleanup forms"). Unwind-protect guarantees to execute the cleanup code before exiting, whether it terminates normally or is aborted (for more detail see Steele's Common Lisp: The Language, p.140). If you have some improtant stuff that must be executed, then you can put it in the cleanup code of an unwind-protect. [Now in LISP you can also abort from the cleanup code, and if you want to do something special in this case then you have to use ANOTHER unwind-protect...] Anyway, I find this very useful because whenever I write code that would cause nasty problems when interrupted, I just put it in an unwind-protect with cleanup code that takes care of things in some minimal way. How could this be done in HyperCard? I guess you could have a special handler AbortHandler which gets invoked immediately upon doing Command-. This handler should run in the binding environment active at the time of the abort (so you could restore things based on the values of local variables). You could use HC 2.0's cantAbort property within the handler if you wanted, though you'd better be careful. Syntactically, it would be nice to be able to define abort handlers in the normal way ("on myAbortHandler1 ...") and then to assign handlers to AbortHandler dynamically. (On entering a particular nasty loop you might want to say "put myAbortHandler1 into AbortHandler"). I hope this provides food for thought... -Lee (spector@cs.umd.edu)
talcott@nunki.usc.edu (Adam Talcott) (09/16/90)
In article <44774@apple.Apple.COM> stadler@Apple.COM (Andy Stadler) writes: > [Stuff deleted] > >Command period is dangerous when it is pressed in the middle of a long script >or during some long operation. By the time you received the "abort" message >the long operation will have long since completed and it won't really be able >to do any good. I disagree. What if the abort message was something like a hardware interrupt. 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... -- | Adam Talcott | Not a bad bit of rescuing, | | talcott@nunki.usc.edu | huh? You know, sometimes I | | Electrical Engineering (Computers) Senior | even amaze myself. | | University of Southern California | --Han Solo |
bc@Apple.COM (bill coderre) (09/16/90)
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. Allegro CL is available for Macintosh and runs like a champ, although it too lacks an application generator. (wry grin) you realize, of course, that these are my personal opinions and we KNOW about them, eh? bill coderre meta linguine abstraction
nayeri@cs.umass.edu (Farshad Nayeri) (09/18/90)
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 <bc@apple.com> 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