wxPython before MainLoop

[david]

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
>