Deferred events

[Steven Swerling]

Rob Gayvert wrote:

> Or you could also just disable the button, no?  The scenario that Cees 
> describes with a lengthy database query is very similar. If the handler 
> is executing Smalltalk code, then subsequent clicks elsewhere could 
> likewise be handled immediately and either ignored or with some kind of 
> busy response. But what if it's off in a primitive or FFI call for an 
> extended period? I don't know what the wx core will do with clicks or 
> keystrokes in this case.  Maybe there's something we can use here from 
> the implementation of WxWindowDisabler.

Yes, agreed on all counts. I lost a little bit the courage of my 
convictions as soon as I hit the send button on that last deferred 
events email. Cees was right that it doesn't clean up the problem, it 
just shifts it.

Perhaps, as you proceed with this difficult problem, you might want to 
leave hooks in the vm so that you can experiment *from smalltalk* with 
different approaches. For example, if you implement a loop in the VM 
that "eats" events during a lengthy sync callback, perhaps you could 
leave a hook in Smalltalk that turns the filter on and off. That way the 
masses can experiment with approaches to the problem by controlling 
event processing from the image. The guy that writes a better WinAmp 
decides not to eat any events, and just handle the consequences by 
putting checks into his own code. The guy that writes a banking 
application says "no, too risky" and disables the interface during 
transaction download.