wxsqueak mailing list
rtg at rochester.rr.com
Tue Feb 22 22:45:08 UTC 2005
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.
More information about the Wxsqueak