[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)!) -- http://mail.python.org/mailman/listinfo/python-list