Today I found that in my wxPython apps, adding a CLR import at the top of the files causes wxPython's mainloop to generate a warning message box which reads "Could not initialize OLE". Otherwise, the application seemed functional. I experimented with it, and it seems that delaying CLR-related imports until after the wx Mainloop has started does the trick. Here's a tiny wxPython app that demonstrates the error: import wx #import CLR class MyApp(wx.App): def OnInit(self): # global CLR # import CLR self.frame = wx.Frame(None, -1, 'Test Window') self.frame.Show(True) return True app = MyApp(0) app.MainLoop() If you uncomment the first comment, the application window will open, and an OleInitialize failure message will pop up. If you instead uncomment the second two comments, the application window will open without error. (Note: this was with the latest wxPython build, 2.5.1.5 - I assume similar failures occur with older builds.) It's not a big deal to move the imports, but it's a little unnatural to me. Is this something that's broken in Python for .NET, or .NET, or... Here's a possibly related message I found on wx-users: http://lists.wxwidgets.org/archive/wx-users/msg30069.html
Today I found that in my wxPython apps, adding a CLR import at the top of the files causes wxPython's mainloop to generate a warning message box which reads "Could not initialize OLE". Otherwise, the application seemed functional. I experimented with it, and it seems that delaying CLR-related imports until after the wx Mainloop has started does the trick.
<snip>
It's late, so forgive any errors in the details, but... This has to do with Deep Voodoo (tm) regarding the CLR and COM compartment initialization. Essentially, whenever you use interop (marshalling to/from native code, etc.), the CLR will have made sure that the process has been initialized to some COM apartment state. Because Python for .NET uses interop extensively (to join the managed world with unmanaged CPython), by the time 'import CLR' finishes, you will be in whatever kind of apartment the CLR deems the default. By your report (and my hazy memory), if you import CLR first you are probably getting the thread initialized as MTA, and OleInitialize probably wants the thread to either be uninitialized or initialized to STA. Your workaround is probably as good as any - there is no real way to change the apartment state from Python once its been intialized (without creating a new thread and doing a lot of things by hand, etc.), since either the CLR itself or some specific unmanaged call (like your OleInitialize) will have made the choice already by the time the CLR/Python layer is bootstrapped. Hope this helps! Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
participants (2)
-
Brian Almond -
Brian Lloyd