wxsqueak mailing list

[Cees de Groot]

On Tue, 22 Feb 2005 17:45:08 -0500, Rob Gayvert <rtg at rochester.rr.com>  
wrote:
> Using deferred events should definitely help prevent crashes, and as a  
> general policy should be used for anything that takes any appreciable  
> amount of time. But I'm not sure what will happen in this scenario if  
> events aren't disabled or consumed in some way. If they pile up in the  
> wx queue while the deferred event is being handled, there's no easy way  
> to ignore them. Should each deferred event be handled in its own  
> process? That would prevent wx events from queing up, but would it make  
> it harder to deal with at the application level?
>
Of course, the application then has to deal with lots of events queued up,  
each consuming appreciable time. For example, say you have retrieved a  
dataset of 10,000 items and there's a refresh button. If the user keeps  
hammering it and you just work around the issue by deferring the extra  
hits on the button, your user is going to stare a long time at the dataset  
being refreshed over and over again...

That is solvable on an application level, of course, but not much cleaner  
than what I currently use (WxWindowDisabler for everything that may take  
long). It's probably cleaner to catch this on a lower level.