wxsqueak mailing list

[Rob Gayvert]

Steven Swerling wrote:

> Cees de Groot wrote:
>
>> On Tue, 22 Feb 2005 07:56:51 -0500, Rob Gayvert 
>> <rtg at rochester.rr.com>  wrote:
>>
>>>> Now that we're chatting. One issue seems to creep up when exposing 
>>>> the   software to actual users over and over again: when an event 
>>>> is being   processed, widgets are not disabled. So if you have a 
>>>> reasonably  lengthy  operation, we've seen users getting impatient 
>>>> and starting to  go into  'gremlin mode' (just clicking around), 
>>>> which prompts a message  from wx  about max event stack depth 
>>>> reached and a subsequent goodbye  from the  image.
>>>>
>>>> I'm plastering the software with WxWindowDisabler instances, but 
>>>> that   doesn't feel like the final solution, somehow ;)
>>>
>>> Ah, real users can be such a pain. I haven't tried long delays like  
>>> this, so I'll have to see what's going on. At worst, we could add 
>>> some  kind of WxReallyDisableItDammit primitive.
>>
>> Or maybe always disable The Works while an event is being handled 
>> inside  Squeak. But I don't know whether that'll work (although it's 
>> probably easy  enough to try...)
>
> Judicious usage of deferred event handling would also help for this 
> problem. The event stack would not fill up if callbacks that take a 
> long time to process are handled from a WorldState>>addDeferred: type 
> function instead of synchonously. If you're not specifically 
> calculating something to be sent back to the WxWidgets libraries (a 
> list of strings for a menu or list box, for instance), than why clog 
> up the event queue?
> I'll officially stop harping on this point. After all, I can always 
> just patch it in for my own apps w/out effecting anything else. Just 
> wanted to get "on record". If callbacks that take a long time get 
> passed off to another process for handling, the "event stack" problem 
> goes away.

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?

Don't stop harping on this; you're absolutely right to be concerned. 
I've been doing simple demos that don't have to deal with real-world 
situations like this, so I haven't been worrying about these kinds of 
problems. This is something we have to handle properly in the core, or 
we'll wind up with a lot of ugly application level code.