On Wednesday, April 24, 2002, at 03:20 AM, Jan Schenkel wrote:
> I'd actually be much more inclined to lock messages > during a lengthy process, just to make sure the user > doesn't accidentally fire that lengthy process a > second time. The TD describes this as preventing card change messages from being called during a card transition. What would be handy is a lock of some sort that one can use to cause all GUI events (including keyboard) during the lock period to be ignored. Is there something like that? Something close? > Also, in order to avoid data-race problems like in > Java's threaded environment, it's better if the > pending messages are handled first, and the gui events > afterwards. Oh, I wasn't complaining. I don't mind which way, but if I'm making stacks, I need to know which way it is. I think it is fine this way. It is good to know I can send in time 0 and know it will be executed before GUI events and I can take advantage of that. My only concern, which I amended from "only one event" to "some events lost" in later mail, is that some events are lost. If that can happen in general and is not a temporary feature on OS X, then I would like a way to lock out the queueing of gui events; they are no longer useful. (I should note that I don't think I have ever seen the first event lost, so in very short, that is, fast, handlers, I wouldn't be concerned.) Dar Scott _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
