WORKAROUND & the Python GUI-lib situation ...

[robert]

PyDenis wrote:

> I fixed problem using Atypes:
> 
> import ctypes
> 
> ctypes.windll.user32.MessageBoxA(0, 'test', 'Title',
> win32con.MB_ICONINFORMATION | win32con.MB_OK |
> win32con.MB_TOPMOST)
> 
> 
> It compiles and runs fine with py2exe.
> 
> 
> Dont remember buggy pywin32 :)
> 


better use win32api.MessageBox
win32api/gui/...  are flat modules unlikely to have errors.

I tested your 2-liner with build207/py2.4.2 and build205/py2.3.5 with 
py2exe and cx_Freeze in each combination and could not reproduce the bug 
on XP, W2K and 98.
( The DestroyWindow bug appears only for more complex apps explicitly 
using .DestroyWindow from certain Notification Handlers; the dual core 
bug does not apply here )

I'm curious what it is?
If you could post a bug - if reproduceable - with all your detailed 
context data to pywin32 project/bugs on sf.net, that would be fine.

--- Python GUI situation:

win32ui most probably is responsible for this bug; its a complex beast 
with lot of descriptional status (MFC).
win32ui wants a mainframe, a document-template, an all that like until 
you can do any simple thing  :-( :-) But once settled and maybe hiding 
its added complexity in a custom wrapper you can program quite fluid 
apps with official Windows look&feel with it.

Yet in my recent tests with wxPython (I tried now 4x over years to get 
something stable with wx :-( ), Boa, Kommodo, ...  I had so much more 
freezes and damages, and fat memory consumption and slowness and 
fatigue, and funny appearance, that I'd say, for Windows its better to 
live with win32ui for non-trivial GUI's (especially distributable ones), 
which appear and behave like real Windows apps - and not like something 
copyied from a Donald Duck magazine.

Testing the latest wx and Boa last week (for py2.3) it hit the 
high-score: All other old win32api/ui apps - just by starting them - 
press magically buttons themslef, raise this and that. Never saw such 
behaviour. wx modified something in the libraries. There were new 
Windows ctrl-libs in the main Python folder after wx-install (which I 
never requested/allowed). But even removing them did not heal the 
ghostly behavor of normal win32 apps not having anything to do with wx. 
Only after uninstalling wx & boa win32 was stable again...

There are some other (open) things like PyFltk and worse ...

In my opinion the overall situation of Python GUI's (platform 
independent) is not in line with and not up to the level of the 
wonderful language itself and to its stability.
There is always a fragile TCL or XY-C++ or MFC or this and that in the 
middle - and I can't believe, that it is necessary. Python is a best OO 
language for GUI programming also and it should glue soon to OS-libs 
(win32api/gui../ctypes , gtk, ...) .

I'd believe there is still room for a relly good, platform independent 
speedy, flat, python-only OO GUI library - which loads modules with 
discipline into memory, allows building distributables below 2MB, raises 
only Python exceptions and would even attack Delphi in terms of 
stability, endurance, VHL language typing speed - first by Pythons 
qualities, and quickly by features (for which people would contribute 
very quickly if a good plan is raised).
( But maybe I'm only dreaming ... ? )

Anygui was an academical test.

Some want to see wx as standard Python GUI lib. In my opinion thats 
compromising cheaply with a C++ monster for producing clumsy test 
in-door apps by carefully avoiding too much stepping with broken builds ..

It is strange, that each of the big python IDE's uses another GUI 
toolkit: In an urge they use everything from Tk and to even the 20MB 
MozillaWindowing-Toolkit (Komodo; I dropped 3.5 yesterday from my HD 
after it core-dumped on second start and stepped 20x slower in the 
debugger than PythonWin, no consistent Interactive Win/history, 100MB in 
memory, .. ).

Python first should maybe have a real Python GUI toolkit and unite the 
OS'es directly - as good as it does for the os module ?


Robert