PyDenis said:
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
