wxsqueak mailing list
sswerling at yahoo.com
Tue Feb 22 20:11:48 UTC 2005
Cees de Groot wrote:
> On Tue, 22 Feb 2005 07:56:51 -0500, Rob Gayvert <rtg at rochester.rr.com>
>>> 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.
More information about the Wxsqueak