Interaction with win32ui

wxPython Users
1

Hi!

I'm observing some strange interaction between wxPython and win32ui
on Windows 7 PCs.

I've been using DDE code from Pythonwin which in turn uses win32ui.
When I use win32ui and SetToolTipString from wxPython in the same
program, the Python interpreter will not exit any more (until it's
killed from the task manager or by closing the console window.)
See below for the code.
If I omit "import win32ui" or "panel.SetToolTipString(...)", then
the interpreter will exit as expected.

The versions:
  pywin32 build 216
  wxPython 2.8.12.0 or 2.8.11.0
  Python 2.7 (same with 2.6 and an older version of wxPython and pywin32)
With Windows XP or 2000 everything works as expected. I think I had the
problem already with Vista, but I'm not sure.

I could re-write the code not to use DDE any more and use e.g.
sockets. But I would prefer to keep DDE.
Any ideas whether there's a workaround?

Regards,

Dietmar

import wx
import win32ui

class MyFrame(wx.Frame):
     def __init__(self, parent):
         wx.Frame.__init__(self, parent, -1, "test frame")
         panel = wx.Panel(self, -1)
         panel.SetToolTipString("test")
         self.Bind(wx.EVT_CLOSE, self.OnCloseWindow)
     def OnCloseWindow(self, event):
         self.Destroy()

import sys
app = wx.App()
frame = MyFrame(None)
frame.Show(True)
app.MainLoop()

print "calling sys.exit()"
sys.exit()

2

Hi!

I'm observing some strange interaction between wxPython and win32ui
on Windows 7 PCs.

I've been using DDE code from Pythonwin which in turn uses win32ui.
When I use win32ui and SetToolTipString from wxPython in the same
program, the Python interpreter will not exit any more (until it's
killed from the task manager or by closing the console window.)
See below for the code.
If I omit "import win32ui" or "panel.SetToolTipString(...)", then
the interpreter will exit as expected.

That is really weird. MainLoop is exiting as expected, but the interpreter appears to hang at the end of the script...

I'm not even sure where to begin guessing. Have you tried asking Mark H. or the PyWin32 mail lists about this? It seems that something that is done during the import of win32ui is conflicting somehow with what is done when a wxToolTip object is created. The wx side of things is not too complex, it basically just adds a new WndProc function to the chain of WndProcs for the window that will respond to the tooltip messages. Maybe win32ui is doing something similar and is getting stuck when it is trying to clean up at exit?

The versions:
pywin32 build 216
wxPython 2.8.12.0 or 2.8.11.0
Python 2.7 (same with 2.6 and an older version of wxPython and pywin32)
With Windows XP or 2000 everything works as expected. I think I had the
problem already with Vista, but I'm not sure.

I could re-write the code not to use DDE any more and use e.g.
sockets. But I would prefer to keep DDE.
Any ideas whether there's a workaround?

It looks like putting a call to wx.Exit() after the MainLoop will work around the problem.

···

On 5/5/11 12:37 PM, Dietmar Schwertberger wrote:

--
Robin Dunn
Software Craftsman

3

It’s strange that your code works fine on my system.

Windows 6.1.7601
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)]
Wx Version 2.8.12.0
Wx Pltform (‘WXMSW’, ‘wxMSW’, ‘unicode’, ‘wx-assertions-on’, ‘SWIG-1.3.29’)

MyFrame::OnCloseWindow() called
main: Calling sys.exit(0)

Note that I also have these packages installed (in this order) :

[PYWIN32](http://sourceforge.net/projects/pywin32/)      (Sourceforge, Mark Hammond)
[WMI](http://pypi.python.org/pypi/WMI/)               (Tim Golden)
[WINSHELL](http://tgolden.sc.sabren.com/python/winshell.html)   (Tim Golden)

One of these might be overriding the misbehaving call that’s giving you grief.

Ray Pasco
pascor(at)verizon(dot)net

4

It's strange that your code works fine on my system.

Windows 6.1.7601
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)]
Wx Version 2.8.12.0
Wx Pltform ('__WXMSW__', 'wxMSW', 'unicode', 'wx-assertions-on',
'SWIG-1.3.29')

>>> MyFrame::OnCloseWindow() called
>>> __main__: Calling sys.exit(0)

That's indeed very strange as it's the same Windows version and I have
tried several PCs with Win 7...
Only difference seems to be Python 2.6.5 vs. 2.7 and 2.6.4

Note that I also have these packages installed (in this order) :

PYWIN32 <http://sourceforge.net/projects/pywin32/&gt; (Sourceforge, Mark
Hammond)
WMI <http://pypi.python.org/pypi/WMI/&gt; (Tim Golden)
WINSHELL <http://tgolden.sc.sabren.com/python/winshell.html&gt; (Tim Golden)

One of these might be overriding the misbehaving call that's giving you
grief.

I've checked WMI and WINSHELL. These are just modules which do not
install anything. So that should not be the reason...

Regards,

Dietmar

···

Am 06.05.2011 18:24, schrieb Ray Pasco:

5

I'm not even sure where to begin guessing. Have you tried asking Mark H.
or the PyWin32 mail lists about this? It seems that something that is
done during the import of win32ui is conflicting somehow with what is
done when a wxToolTip object is created. The wx side of things is not
too complex, it basically just adds a new WndProc function to the chain
of WndProcs for the window that will respond to the tooltip messages.
Maybe win32ui is doing something similar and is getting stuck when it is
trying to clean up at exit?

I've just posted on python-win32, including your comment.

It looks like putting a call to wx.Exit() after the MainLoop will work
around the problem.

Yes, this works for me. Thanks a lot.

Regards,

Dietmar

···

Am 06.05.2011 06:12, schrieb Robin Dunn:

6

I've got the same problem on 2 PC.
The first has :
- wxPython 2.8.11.0
- PyWin32 210
- Python 2.5
- Windows Vista

And the second :
- wxPython 2.8.12.0
- Pywin32 216
- Python 2.7
- Windows 7

...

···

On May 7, 12:01 pm, Dietmar Schwertberger <maill...@schwertberger.de> wrote:

That's indeed very strange as it's the same Windows version and I have
tried several PCs with Win 7...
Only difference seems to be Python 2.6.5 vs. 2.7 and 2.6.4
I've checked WMI and WINSHELL. These are just modules which do not
install anything. So that should not be the reason...

--
Pascal BRIET