wxPython before MainLoop

[Bjoern Schliessmann]

[david] wrote:

> I'm disappointed that I didn't get a wxPython solution.
> 
> If the only way to get wxPython to correctly handle
> this simple task is to code around it, 

LOL -- did you try coding this app with native windows means, like
MFC? You will have *exactly* the same problem, and *exactly* for
the same reason. The organisation of wxWidgets (and thus, wxPython)
is very near to Windows GUI coding philosophy.

> I don't think wxPython is really ready for Windows.

I suggest you first went getting experience with other GUI libraries
before you make such statements. 

Also, wxPython is a thin wrapper around wxWidgets C++ library which
is widely used for Windows apps. And with wxWidgets, you'd *also*
have the same problem.

> Bjoern, you're wrong. The GUI needs to be displayed
> for the user to analyse. A delay between display and
> readiness is much better than a delay before display
> or a delay with the GUI half-drawn.

This may be, but it strongly depends on the application itself.
 
> Mike, the screen does display correctly, it's just
> that in Windows, screen updates are not processed
> while the application is busy.

That's the matter in just about *every* GUI framework using an event
loop. And I don't know any that doesn't. Thus, there are two widely
used standard solutions:

* use a worker thread, or

* call a "process all pending events now" function repeatedly during
  the work (here: wx.Yield, wx.SafeYield, wx.YieldIfNeeded).

Regards,


Björn

-- 
BOFH excuse #92:

Stale file handle (next time use Tupperware(tm)!)