wxsqueak mailing list

[Steven Swerling]

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.