send ___ to me in ___ sec

[Dar Scott]

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