> Scott,
> Why not support the Supercard's excellent "flushevents" command? It
> allows you to specify what kinds of events to flush (e.g. mouse, all).
> Or perhaps you could consider extending "exit to metacard" to flush all
> pending messages as well as exit scripts.
It's an XCMD (in Xtend) rather than a built-in, but it looks like
it does exactly what I was describing. The only problem with it is
the non-English-like syntax:
flushevents mouseDown, mouseUp
Extending "exit" would be risky, I think. Too much likelihood of
breaking existing scripts.
Our two front runners at this point are:
1) making a "pendingEvents" property that you could use to get a list
of all the events in the queue. Deleting just a few of a particular
type would be kind of tricky: you'd have to delete them out of the
property and then set it again. Deleting all of them would be easy:
set the pendingEvents to empty
2) Add a "dispatch events" command, that would cause all pending
messages to be delivered. This would solve the problem in question
(the messages would be sent while the button was disabled), but could
get hairy if the messages send cause the handler (or some other
long-running handler) to be called again. It would also allow
something that people occasionally ask for: you could process keyboard
events while inside another handler, something that's impossible to do
now since there is no analog to the "mouseClick" function for key
presses.
Other options are to do it exactly like flushevents as defined in
Xtend, or make a flushEvents(<type>) function which might return
something like the number of events flushed (at least the syntax
doesn't clash with the latter).
Preferences?
Scott
> Kevin.
>
***************************************************************
Scott Raney raney@metacard.com http://www.metacard.com
Any sufficiently advanced technology
is virtually indistinguishable from magic -- Clark's law