Hi Dar and all, > > 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
during this (loooong ;-) thread i have never seen "lock messages" or "set the lockmessages to true" in all the mails... Maybe this could be of some use ? Well, maybe not... ;-) Best Klaus Major [EMAIL PROTECTED] _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
