James: > Hi folks, I have been working on a database front end in REBOL/View and > while testing the display aspects for subform switching have managed to get > rebol to crash (in Windows2000) on a regular basis
Nice looking buttons! It's them waits in the action facets. You are creating simultaneous threads and rebol don't like that much as yet. Check the list archives for subject "multiple threads crash". Holger wrote in that thread: << Calling 'wait from within an awake handler is not really supported. It is bad style anyway, because in event-driven systems event handlers are not allowed to block. That's because blocking in an event handler makes programs extremely difficult to debug, in particular if the list of handlers (meaning, faces) is modified while another handler is suspended. The problem is that all those suspended handlers carry hidden "context" around with them, and you might end up with an "old" handler being woken up from suspension after the face it has been associated with has already been removed from the pane, by a different handler. Other complications are possible, as well. It is extremely difficult to foresee all of these side effects, so programs that use tricks like that are bound to be buggy and full of race conditions. As for the crashes, this is the result of a limit on recursion in current REBOL versions. Should be eliminated in one of the next version. >> But you probably do want to keep the waits. That way a user can interrupt a long-running action. Change them to wait 0, and you now have these two issues: 1. A long running process (such as running a monthly report) may create multiple threads -- the user can click any other button while the action is underway -- or even click multiple times on the same button. To handle that, you need a global variable that tells you if you have an action facet running. Check it at the start of every action. Return immediately if it is true, otherwise set it and continue. Remember to unset it at all the return points or the whole application gets blocked. 2. For good user relations (and the reason for wait 0 is), the user needs a way to cancel a long-running action. My application (which looks similar to your, but with less snazzy buttons) has a "Cancel button". If the user clicks that, it sets a global "stop it" variable. Long-running action facets check for this variable at regular intervals. Sunanda. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
