I thought I had this figured out but as I'm putting together a preview for the next release I see that there is still a problem and I thought that I would ask you guys to see if you have any better ideas than I do. The issue is how to get the new common controls DLL to be loaded on XP and Vista so the application will use the new themed controls. If that version of the DLL is not loaded then the system will fall back to the older Win2000 version of the common controls and the app will look really ugly and out of place.
In the past we've dealt with this simply by installing python.exe.manifest and pythonw.exe.manifest files as part of the wxPython installation, and the system would see this file when Python starts, read it, and then load the new version of the common controls.
Now with Python 2.6 being built with MSVC 9 the stock python executable already has a manifest file linked in to the .exe, but it only specifies the MS C runtime library as a dependency and not the common controls DLL. On 32-bit XP it appears that using the python.exe.manifest trick still works, but at least on XP-x64 and Vista-x64 it does not work. If I replace the manifest resource inside the python executable then it will load the new common controls, but that is a fairly icky thing to do so I would really rather not do that if I can avoid it.
I noticed that distutils is also now putting a manifest into the wxPython .pyd files, and the compiler is sensing that it needs the common controls, so they include the manifest info for both the CRT and the common controls DLL, but it doesn't seem to have any effect on what is loaded at runtime. The wx DLLs do not automatically get a manifest linked in, although the compiler does generate one. I linked the manifest in by hand to check if that would help, but it does not.
So to finally get to the point of this message: Does anybody here have any ideas (or better Google searches than I did) for how to get the new common controls DLL loaded automatically without requiring the wxPython installer to update the python.exe and pythonw.exe binaries?
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
In the future, I was thinking of building a "local" wxPython env using virtualenv (virtualenv · PyPI) and patching the embedded manifest of the local python.exe, which I think will work. That, at least, gets out of the business of touching the Program Files pyhon install.
However, I haven't tested it, and it's still not an ideal solution. I'm returning to some wxPython dev next week, and may also look for a more savory workaround on Vista 64.
Rod
Robin Dunn wrote:
···
Hi All,
I thought I had this figured out but as I'm putting together a preview for the next release I see that there is still a problem and I thought that I would ask you guys to see if you have any better ideas than I do. The issue is how to get the new common controls DLL to be loaded on XP and Vista so the application will use the new themed controls. If that version of the DLL is not loaded then the system will fall back to the older Win2000 version of the common controls and the app will look really ugly and out of place.
In the past we've dealt with this simply by installing python.exe.manifest and pythonw.exe.manifest files as part of the wxPython installation, and the system would see this file when Python starts, read it, and then load the new version of the common controls.
Now with Python 2.6 being built with MSVC 9 the stock python executable already has a manifest file linked in to the .exe, but it only specifies the MS C runtime library as a dependency and not the common controls DLL. On 32-bit XP it appears that using the python.exe.manifest trick still works, but at least on XP-x64 and Vista-x64 it does not work. If I replace the manifest resource inside the python executable then it will load the new common controls, but that is a fairly icky thing to do so I would really rather not do that if I can avoid it.
I noticed that distutils is also now putting a manifest into the wxPython .pyd files, and the compiler is sensing that it needs the common controls, so they include the manifest info for both the CRT and the common controls DLL, but it doesn't seem to have any effect on what is loaded at runtime. The wx DLLs do not automatically get a manifest linked in, although the compiler does generate one. I linked the manifest in by hand to check if that would help, but it does not.
So to finally get to the point of this message: Does anybody here have any ideas (or better Google searches than I did) for how to get the new common controls DLL loaded automatically without requiring the wxPython installer to update the python.exe and pythonw.exe binaries?