tonyrich@titanic.cs.wisc.edu (Anthony Rich) (03/29/91)
Here's another feature I'd like to add to the HyperCard Pro wishware list: the script commands SUSPEND and RESUME. SUSPEND would save the entire state of the script in which it's executed, then give up control to the HyperCard user. RESUME would resume the execution of a SUSPENDed script by restoring the state of the script to what it was at the time it was SUSPENDed and letting the script keep executing from that point -- just as if it had never been suspended. If no SUSPEND was pending, RESUME would do nothing. If several handlers were suspended, RESUME would resume the most recently suspended one, or RESUME <handlername> could be used to resume a certain one. (Note to the nitpicky: Yes, I know HyperCard has "suspend" and "resume" messages, but they don't act like that.) Why would anyone want such a thing? Well, I wanted it when I used HyperCard to do a quick-and-dirty prototype of a user interface. I wrote a script that did some setup work and created a card with a big, empty field on it for a user to type into as a kind of pretend text editor. I wanted the setup script to SUSPEND so that the user could do some text entry into that field (that is, to let them use the "text editor"). When the user was done editing, he or she could then press a "DONE" button. That would cause the setup script to RESUME so that it could then store the user's text on a fresh card and do some card linking. The script had some info sitting in local variables that it needed to use both before and after the user's simulated "editing session"; in fact, I think the editing session took place inside a loop that needed to keep looping. I was able to fake doing the SUSPEND/RESUME by saving all the values of the script's local variables in a hidden field, then restoring them from that field...but that's a *really* messy thing to have to do. It seems like SUSPEND/RESUME would be an easy thing to implement in HyperCard Pro, though. It would be nice if the "open <application>" command worked that way, too. It should SUSPEND the script and launch the application, then when the application quits, the suspended script should resume *exactly from the point at which it was suspended, with all its local variables intact*. Then I wouldn't have had to fake a text editor -- I could have used a REAL word processor, like TeachText! :) The "open <application>" command *doesn't* work that way. When you quit the launched application, it returns to the card you left and sends a "resume" message, but the script that launched the app doesn't automatically resume. All local variables are gone bye-bye. So an application launch acts like a sort of brain-damaged procedure call; you can't get back here from there. Interestingly, you can't cheat and use "open HyperCard" to give control to the user by re-launching HyperCard, then resume after the re-launched HyperCard application is quit. "open HyperCard" is TOO smart; apparently it notices that HyperCard is already running and does nothing. Even if it *did* work, it would probably launch to the first card of some stack, not to a specific card you wanted it to go to...sigh. I guess that's why we need HyperCard Pro. ;^) -- Tony -- ----------------------------------------------------------------------- | EMAIL: tonyrich@cs.wisc.edu | The essence of learning is | | Disclaimer: I speak only for myself. | repetition, repetition! | -----------------------------------------------------------------------