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