Just mulling the thought over... If a substack was tagged as being Threaded, then it couldn't "see" objects or events outside of itself. It would have its own event list that runs separately. So if the main stack is in the middle of a long process, the substack would still be interactive.
The threaded stack CAN see the message list of the mainstack's thread, or at least it can drop something onto it. That would be how they pass information between them, sending messages. So you could make a threaded substack with a progress bar and a Cancel button. the mainstack can be deep in a single long function, sending progress update events to the threaded substack. While the mainstack would be unresponsive to the user - as it would be now - the progress dialog would still work. Clicking the Cancel button would send a message to the mainstack, to be executed when possible. Or while in a long function, the code can check to see if the cancel event is queued up, and abort early. The advantage to this method of threading is that it doesn't require the users to handle resource locking (which is a pain) or require the engine to have built-in resource locking on EVERY command (which would slow everything down). It puts the built-in locking in just one place, the message queue. My example can also be turned around so that the substack is doing the heavy lifting, and might not even be visible to the user. Probably a better design pattern. When its done it can send the results of its labors to the mainstack as an event with parameters. Meanwhile, the mainstack remains fully interactive to the user. Anyway, just an idle thought about how to quickly add a very usable version of threading to LiveCode without major code changes. ~ Chris Innanen ~ Nonsanity _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
