I'm in the middle of embedding wxPython in an existing wxWidgets application. I have it up and running on OS X, but it doesn't work properly on Windows:
After importing wx._core_, wxWidgets cannot create new Windows any more. Calls to CreateWindowEx. fail with error 1407, "Can't find Windows Class". The very same calls work fine when called before importing wx._core_. This happens regardless of whether the windows are created from C++ or Python.
I'm using Python 2.4.2 and wxWidgets 2.8.9. I build Python and wxWidgets with Visual Studio 2008, wxPython with the distutils from the custom Python build.
Unfortunately, wxPython is SWIG generated code which makes it hard to read. What exact steps does wxPython go through when it's instantiated? Are there any interesting calls to wxWidgets that it makes upon loading that I can place breakpoints in?
I'm in the middle of embedding wxPython in an existing wxWidgets application. I have it up and running on OS X, but it doesn't work properly on Windows:
After importing wx._core_, wxWidgets cannot create new Windows any more. Calls to CreateWindowEx. fail with error 1407, "Can't find Windows Class". The very same calls work fine when called before importing wx._core_. This happens regardless of whether the windows are created from C++ or Python.
I'm using Python 2.4.2 and wxWidgets 2.8.9. I build Python and wxWidgets with Visual Studio 2008, wxPython with the distutils from the custom Python build.
Be sure that both wxPython and your application are using the same instance of wxWidgets and that it is not getting loaded twice. The best way to do that is to build wxWidgets as DLLs and then ensure those DLLs are found first by setting the PATH.
Unfortunately, wxPython is SWIG generated code which makes it hard to read. What exact steps does wxPython go through when it's instantiated? Are there any interesting calls to wxWidgets that it makes upon loading that I can place breakpoints in?
Most of the wx initialization happens when the wxApp is created, and since there is already an app in your C++ code you should not be creating a new one from Python. (Although IIRC it is checking for that and skipping some of the initialization if it's already been done...) Anyway, when the wx._core module is first imported Python calls its init_core_ function so that would be a good starting place for a breakpoint.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Be sure that both wxPython and your application are using the same instance of wxWidgets and that it is not getting loaded twice. The best way to do that is to build wxWidgets as DLLs and then ensure those DLLs are found first by setting the PATH.
Thanks. I'm pretty sure they're using the same set of DLLs since there's only one copy of them on my drive. Also, I don't remember seeing any information about loading extra DLLs in the output window of Visual Studio.
Most of the wx initialization happens when the wxApp is created, and since there is already an app in your C++ code you should not be creating a new one from Python. (Although IIRC it is checking for that and skipping some of the initialization if it's already been done...) Anyway, when the wx._core module is first imported Python calls its init_core_ function so that would be a good starting place for a breakpoint.
Thanks, I will have a look there.
Another suspicion I have is that my port of the 2.6 distutils for Visual Studio 2008 to 2.4 wasn't as perfect as I hoped. While I can build a working Python 2.4 using Visual Studio 2008, the distutils that come with 2.4 don't know how to compile extensions. I had to grab some code from Python 2.6 in order to build wxPython, and maybe my .pyds where built with the wrong settings to run properly.
I will try if I can build the entire thing with Python 2.6 and see what that does.
After getting the same result when building with Python 2.6, I'm trying a manual debug now. I'm building wxPython with distutils, --debug and DEBUG=1 are both set. Visual Studio won't find any debug information for the *_d.pyd files, so I can't step through the code comfortably. Is there a secret to build wxPython from distutils so that Visual Studio finds all the debug symbols? I see in the build output that the modules get build wiht /pdb:None, where can I change this to generate pdb files?
-Stefan
···
On Mar 9, 2009, at 11:09 AM, Robin Dunn wrote:
Unfortunately, wxPython is SWIG generated code which makes it hard to read. What exact steps does wxPython go through when it's instantiated? Are there any interesting calls to wxWidgets that it makes upon loading that I can place breakpoints in?
Most of the wx initialization happens when the wxApp is created, and since there is already an app in your C++ code you should not be creating a new one from Python. (Although IIRC it is checking for that and skipping some of the initialization if it's already been done...) Anyway, when the wx._core module is first imported Python calls its init_core_ function so that would be a good starting place for a breakpoint.