wxPython before MainLoop

[Chris Mellon]

On 8/15/07, samwyse <dejanews at email.com> wrote:
> Chris Mellon wrote:
> > On 8/9/07, Heikki Toivonen <heikki at osafoundation.org> wrote:
> >
> >>[david] wrote:
> >>
> >>>I'd like to refresh the display before I start the main loop.
>
> If your window isn't able to interact with the user, then I'd consider
> it a splash screen, no matter if it does look exactly like your main
> application interface.
>
> >>We have this kind of situation in Chandler, where we display and update
> >>the splash screen before we enter MainLoop.
> >>
> [...]
> >>3. The splash screen refresh is basically: draw new stuff,
> >>self.Layout(), self.Update(), wx.Yield()
> >>http://lxr.osafoundation.org/source/chandler/application/Application.py#1421
>
> Looking at the Chandler code suggests a solution to [david]'s original
> problem.  It is possible that, on Windows only, he may need to call
> Update to finish painting the display.
>
> 1432         self.Layout()
> 1433         if wx.Platform == '__WXMSW__':
> 1434             self.Update()
> 1435         wx.GetApp().Yield(True)
>
> > wxYield spins the event loop in place. This can have some serious
> > consequences if you aren't very careful with your usage, like
> > recursively entering event handlers. I generally consider it an
> > experts only interface, and avoid it.
>
> I'll confess to being one of those old-school programmers who, back in
> the day, wrote his code around big select loops instead of using
> threads, but I'm intriged by the "experts only" designation.  Can
> someone explain further?  Thanks!

The biggest problem is recursive events. You can end up entering an
event handler downstack from itself. There's other common problems -
event handlers are generally written to be short and sweet and not to
expect recursion and to complete without interruption. wxYield can
easily end up breaking that. Components that call wxYield are
especially dangerous. For example, some parts of wxWidgets call
wxYield internally. An event handler that aquired a lock was changed
to use one of those components and ended up deadlocking when it was
re-entered by the yield. I've also seen crashes when wxYield processed
a destroy event for a window in the middle of it's own event handler.

Because analyzing your event code to make sure it's reentrant is hard,
and is complicated even more by the fact that wxYield in a component
can cause problems far upstack in a caller, and because there is an
excellent alternative in the form of python generators, I avoid it's
usage from wxPython entirely.