Well yes, I have tried this app with native windows, and I know how to do it.
But if all wxPython can offer is a poor imitation of MFC, I'm better off using MFC aren't I? And too all those people who wrote back to insist that users MUST explicitly build a multi-threaded framework for wxPython: It's supposed to already be a framework :~) (david) Bjoern Schliessmann wrote: > [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 > -- http://mail.python.org/mailman/listinfo/python-list
