[wxpython-users] ANN: wxPython 2.8.10.1
Robin Dunn
----------
The 2.8.10.1 release of wxPython is now available for download at
http://wxpython.org/download.php. This release fixes the problem with
using Python 2.6's default manifest, and updates wxcairo to work with
the latest PyCairo. A summary of changes is listed below and also
at http://wxpython.org/recentchanges.php.
Source code is available as a tarball and a source RPM, as well as
binaries for Python 2.4, 2.5 and 2.6, for Windows and Mac, as well
some packages for various Linux distributions.
What is wxPython?
-----------------
wxPython is a GUI toolkit for the Python programming language. It
allows Python programmers to create programs with a robust, highly
functional graphical user interface, simply and easily. It is
implemented as a Python extension module that wraps the GUI components
of the popular wxWidgets cross platform library, which is written in
C++.
wxPython is a cross-platform toolkit. This means that the same program
will usually run on multiple platforms without modifications.
Currently supported platforms are 32-bit and 64-bit Microsoft Windows,
most Linux or other Unix-like systems using GTK2, and Mac OS X 10.4+.
In most cases the native widgets are used on each platform to provide
a 100% native look and feel for the application.
Changes in 2.8.10.1
-------------------
wx.grid.Grid: Added methods CalcRowLabelsExposed,
CalcColLabelsExposed, CalcCellsExposed, DrawRowLabels, DrawRowLabel,
DrawColLabels, and DrawColLabel to the Grid class.
Added the wx.lib.mixins.gridlabelrenderer module. It enables the use
of label renderers for Grids that work like the cell renderers do. See
the demo for a simple sample.
Solved the manifests problem with Python 2.6 on Windows. wxPython now
programatically creates its own activation context and loads a
manifest in that context that specifies the use of the themable common
controls on Windows XP and beyond. This also means that the external
manifest files are no longer needed for the other versions of Python.
wx.Colour: Updated the wx.Colour typemaps and also the wx.NamedColour
constructor to optionally allow an alpha value to be passed in the
color string, using these syntaxes: "#RRGGBBAA" or "ColourName:AA"
wx.lib.wxcairo: Fixed a problem resulting from PyCairo changing the
layout of their C API structure in a non-binary compatible way. The
new wx.lib.wxcairo is known to now work with PyCairo 1.6.4 and 1.8.4,
and new binaries for Windows are available online at
http://wxpython.org/cairo/
--
Robin Dunn
Software Craftsman
http://wxPython.org
Christoph Willing
On 17/05/2009, at 4:12 PM, Mario Lacunza wrote:
> Hello Robin,
>
> Great! but there are a version for Ubuntu 9.04 amd64?
http://apt.wxwidgets.org/dists/jaunty-wx/main/binary-amd64/
To install the packages with apt*, see:
http://wiki.wxpython.org/InstallingOnUbuntuOrDebian
> 2009/5/17 Robin Dunn <ro...@alldunn.com>
> _______________________________________________
> wxpython-users mailing list
> wxpytho...@lists.wxwidgets.org
> http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
>
>
>
> --
> Saludos / Best regards
>
> Mario Lacunza
> Software Architect - Webmaster
>
> Website: http://www.lacunza.biz
> Email: mlacunza [AT] gmail [DOT] com
> Lima - Peru
>
> _______________________________________________
> wxpython-users mailing list
> wxpytho...@lists.wxwidgets.org
> http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
Mario Lacunza
Great! but there are a version for Ubuntu 9.04 amd64?
Mario
_______________________________________________
wxpython-users mailing list
wxpytho...@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
Chris Spencer
Two problems I have encountered.
1) I still need the manifest file in the same directory as the
executable when running a program frozen with py2exe. I get errors if
it is not there. I thought this release was supposed to eliminate the
need for the manifest file? Do I need the msvcr*,msvcp* dlls in the
same directory as the executable in order to remove the need for a
manifest file? Some documentation here might help.
2) In one of my programs (again, "compiled" with py2exe), I am
getting a strange debugging statement when running the executable from
the command line:
"""
16:11:41: Debug: src/helpers.cpp(140): 'CreateActCtx' failed with
error 0x000000
7b (the filename, directory name, or volume label syntax is
incorrect.).
"""
It doesn't seem to affect the functioning of my program, but I just
want to make sure I can ignore this and it won't bite me in the butt
in the future.
Thanks in advance for any help you may be able to give!
Chris.
Werner F. Bruhin
Chris Spencer wrote:
> Thank you for releasing this version, Robin.
>
> Two problems I have encountered.
> 1) I still need the manifest file in the same directory as the
> executable when running a program frozen with py2exe. I get errors if
> it is not there. I thought this release was supposed to eliminate the
> need for the manifest file?
This might only be the case with Py2.6.
> Do I need the msvcr*,msvcp* dlls in the
> same directory as the executable
You still need the dll's either in the application folder or with Py2.6
they can also be in the Windows SxS folder, but I have not figured out
how to get them installed in there with ones own installer e.g.
InnoSetup, there is a MS installer but it is pretty large and just
yesterday I found on some MS VC++ blog post that it is not recommended
to use this stand alone installer unless one does "One click install"
(don't ask I have no clue what that is).
> in order to remove the need for a
> manifest file? Some documentation here might help.
>
I started documenting my findings testing py2exe with Py2.6 on the wiki.
http://wiki.wxpython.org/Deployment
This is still work in progress as I am still finding out new things, so
will keep updating the py2exe page in the next couple of days.
Depending on py2exe settings (e.g. using "lib" sub-folder) requires two
copies of the MS.CRT.manifest and the dll's, still trying to find a
solution for this. I have posted some of this on the list here, see the
thread "[wxpython-users] py2exe and Py2.6" and "Re: [wxpython-users] Re:
[wxpython-dev] 20090503 test build uploaded*".*
> 2) In one of my programs (again, "compiled" with py2exe), I am
> getting a strange debugging statement when running the executable from
> the command line:
>
> """
> 16:11:41: Debug: src/helpers.cpp(140): 'CreateActCtx' failed with
> error 0x000000
> 7b (the filename, directory name, or volume label syntax is
> incorrect.).
> """
>
> It doesn't seem to affect the functioning of my program, but I just
> want to make sure I can ignore this and it won't bite me in the butt
> in the future.
>
It might help if you can track down what is causing this in your code,
are you using something like a FileDiag and feeding it a filename,
directory or volume which is maybe not correct?
Werner
Chris Spencer
and without this debug statement under the previous version of
wxPython.
This debug statement seems to come from the new mechanism for
"auto-generation" of the manifest in the new version of wxPython,
given the function's purpose:
From Microsoft's website:
"""
Activation contexts are data structures in memory containing
information that the system can use to redirect an application to load
a particular DLL version, COM object instance, or custom window
version. One section of the activation context may contain DLL
redirection information which is used by the DLL loader; another
section may contain COM server information. The activation context
functions use, create, activate, and deactivate activation contexts.
The activation functions can redirect the binding of an application to
version-named objects that specify particular DLL versions, window
classes, COM servers, type libraries, and interfaces. For more
information about the activation context functions and structures, see
the Activation Context Reference.
"""
This tells me that this is part of the manifest file solution Robin
was trying to institute.
Given what I'm seeing so far, it looks like this addition causes more
harm than good.
Chris.
On Mon, 18 May 2009 09:27:59 +0200, "Werner F. Bruhin"
<werner...@free.fr> wrote:
>Chris,
>> 2) In one of my programs (again, "compiled" with py2exe), I am
>> getting a strange debugging statement when running the executable from
>> the command line:
>>
>> """
>> 16:11:41: Debug: src/helpers.cpp(140): 'CreateActCtx' failed with
>> error 0x000000
>> 7b (the filename, directory name, or volume label syntax is
>> incorrect.).
>> """
>>
>> It doesn't seem to affect the functioning of my program, but I just
>> want to make sure I can ignore this and it won't bite me in the butt
>> in the future.
>>
>It might help if you can track down what is causing this in your code,
>are you using something like a FileDiag and feeding it a filename,
>directory or volume which is maybe not correct?
>
>Werner
>
Werner F. Bruhin
Chris Spencer wrote:
> I can assure you that it isn't in my code, as my code works just fine,
> and without this debug statement under the previous version of
> wxPython.
>
> This debug statement seems to come from the new mechanism for
> "auto-generation" of the manifest in the new version of wxPython,
> given the function's purpose:
>
> From Microsoft's website:
> """
> Activation contexts are data structures in memory containing
> information that the system can use to redirect an application to load
> a particular DLL version, COM object instance, or custom window
> version. One section of the activation context may contain DLL
> redirection information which is used by the DLL loader; another
> section may contain COM server information. The activation context
> functions use, create, activate, and deactivate activation contexts.
> The activation functions can redirect the binding of an application to
> version-named objects that specify particular DLL versions, window
> classes, COM servers, type libraries, and interfaces. For more
> information about the activation context functions and structures, see
> the Activation Context Reference.
> """
>
> This tells me that this is part of the manifest file solution Robin
> was trying to institute.
>
Looks like it.
> Given what I'm seeing so far, it looks like this addition causes more
> harm than good.
>
What Python version are you using?
What OS version?
I haven't tried this new wxPython build with Py 2.5.4 as I am in the
midst of releasing a version of my own soft and I don't want to risk
messing something up, but I tried it with Py 2.6.2 (both on Vista and
Win7 and run the test app on XP) and with that this manifest stuff seems
to work, actually without one could not py2exe an app. I.e. I do not
include a manifest for my app, only the MS.CRT one, unfortunately if I
tell py2exe to put wx and other stuff into a sub-folder (lib) I have to
include this MS stuff twice.
Werner
Jorge
update-alternatives: unable to make /usr/lib/python2.6/site-packages/wx.pth.dpkg-tmp a symlink to /etc/alternatives/wx-python2.6.pth: No such file or directory
any ideas?
Thank you.
Mike Driscoll
> Chris,
>
> Chris Spencer wrote:
>> Thank you for releasing this version, Robin.
>>
>> Two problems I have encountered.
>> 1) I still need the manifest file in the same directory as the
>> executable when running a program frozen with py2exe. I get errors if
>> it is not there. I thought this release was supposed to eliminate the
>> need for the manifest file?
> This might only be the case with Py2.6.
>> Do I need the msvcr*,msvcp* dlls in the
>> same directory as the executable
> You still need the dll's either in the application folder or with
> Py2.6 they can also be in the Windows SxS folder, but I have not
> figured out how to get them installed in there with ones own installer
> e.g. InnoSetup, there is a MS installer but it is pretty large and
> just yesterday I found on some MS VC++ blog post that it is not
> recommended to use this stand alone installer unless one does "One
> click install" (don't ask I have no clue what that is).
You should be able to use Inno to place the files in the correct
folder...but I don't think it has a way to register them with Windows.
You may be able to run a post-install script or batch file that does it
though. All you need to run is the following for each dll:
regsvr32 <path & filename of dll or ocx>
I've used Python subprocess module to do this. You could have your
application do some kind of check on startup to see if the files are
registered and if not, do the above.
HTH
-------------------
Mike Driscoll
Werner F. Bruhin
Mike Driscoll wrote:
> Werner F. Bruhin wrote:
...
>> You still need the dll's either in the application folder or with
>> Py2.6 they can also be in the Windows SxS folder, but I have not
>> figured out how to get them installed in there with ones own
>> installer e.g. InnoSetup, there is a MS installer but it is pretty
>> large and just yesterday I found on some MS VC++ blog post that it is
>> not recommended to use this stand alone installer unless one does
>> "One click install" (don't ask I have no clue what that is).
>
> You should be able to use Inno to place the files in the correct
> folder...but I don't think it has a way to register them with Windows.
> You may be able to run a post-install script or batch file that does
> it though. All you need to run is the following for each dll:
>
> regsvr32 <path & filename of dll or ocx>
This can be done in InnoSetup run section, e.g.:
[Run]
Filename: {sys}\regsvr32.exe; Parameters: """{sys}""OdbcFb32.dll -s"
>
> I've used Python subprocess module to do this. You could have your
> application do some kind of check on startup to see if the files are
> registered and if not, do the above.
However I am not sure that this is valid/enough for all the MS.CRT stuff
to ensure that it goes into the right place and gets all the right
registry entries on all the different MS OS versions, did quit a bit of
googling but haven't had much luck. There is a post indicating that one
could include an .msi file with InnoSetup (or other installers) and then do:
[Run]
Filename: "msiexec.exe"; Parameters: "/i ""{tmp}\Your-MSI-File.msi"""
BTW the post giving the above hint is well before MS came up with SxS to
solve all our dll problems. :-)
I have not found an .msi with the MS.CRT version 9 (found some v 6 and v
7, so I think MS has changed the rules with v 8 and all this SxS stuff).
Even an 'app-local' install does not work the same on all the different
MS OS's, e.g. just found out that on Windows 2000 I can not put the
stuff into a sub-folder, where this is one of the MS recommendations and
seems to work from XP + (also can not fully confirm as I don't have a
Vista nor Win7 machine without all the dev tools).
Werner
Mike Driscoll
> Mike,
>
> Mike Driscoll wrote:
>> Werner F. Bruhin wrote:
>
> ...
>>> You still need the dll's either in the application folder or with
>>> Py2.6 they can also be in the Windows SxS folder, but I have not
>>> figured out how to get them installed in there with ones own
>>> installer e.g. InnoSetup, there is a MS installer but it is pretty
>>> large and just yesterday I found on some MS VC++ blog post that it
>>> is not recommended to use this stand alone installer unless one does
>>> "One click install" (don't ask I have no clue what that is).
>>
>> You should be able to use Inno to place the files in the correct
>> folder...but I don't think it has a way to register them with
>> Windows. You may be able to run a post-install script or batch file
>> that does it though. All you need to run is the following for each dll:
>>
>> regsvr32 <path & filename of dll or ocx>
> This can be done in InnoSetup run section, e.g.:
> [Run]
> Filename: {sys}\regsvr32.exe; Parameters: """{sys}""OdbcFb32.dll -s"
I didn't actually look into it...so I'm too surprised. I just figured
you would have mentioned it earlier. :)
>>
>> I've used Python subprocess module to do this. You could have your
>> application do some kind of check on startup to see if the files are
>> registered and if not, do the above.
> However I am not sure that this is valid/enough for all the MS.CRT
> stuff to ensure that it goes into the right place and gets all the
> right registry entries on all the different MS OS versions, did quit a
> bit of googling but haven't had much luck. There is a post indicating
> that one could include an .msi file with InnoSetup (or other
> installers) and then do:
>
> [Run]
> Filename: "msiexec.exe"; Parameters: "/i ""{tmp}\Your-MSI-File.msi"""
>
> BTW the post giving the above hint is well before MS came up with SxS
> to solve all our dll problems. :-)
>
> I have not found an .msi with the MS.CRT version 9 (found some v 6 and
> v 7, so I think MS has changed the rules with v 8 and all this SxS
> stuff).
>
> Even an 'app-local' install does not work the same on all the
> different MS OS's, e.g. just found out that on Windows 2000 I can not
> put the stuff into a sub-folder, where this is one of the MS
> recommendations and seems to work from XP + (also can not fully
> confirm as I don't have a Vista nor Win7 machine without all the dev
> tools).
>
> Werner
This definitely sucks. I'll probably have to start researching this too
then. Ugh.
Mike
Chris Spencer
I am using 2.6.2
>What OS version?
I'm using Windows XP, Service Pack 3
Since this release doesn't give me the ability to remove the manifest
file, nor does it solve the DLL hell we seem to be in, I am going to
temporarily go back to using the old version of wxPython.
I'd like to get out of this DLL hell, and I'd love to eliminate the
manifest file. I don't mind dumping the DLLs into my executable
directory if it will make frozen wxpython programs just WORK. Right
now, though, I think this release may be a situation of "one step
backwards".
I really wish python 2.6.2 was compiled so that it didn't depend on
the screwed up SxS Microsoft crap.
Chris "frustrated" Spencer
Robin Dunn
> Thank you for releasing this version, Robin.
>
> Two problems I have encountered.
> 1) I still need the manifest file in the same directory as the
> executable when running a program frozen with py2exe. I get errors if
> it is not there. I thought this release was supposed to eliminate the
> need for the manifest file?
The .exe itself will probably still need a manifest to allow it to load
the MS C runtime DLLs. Using a copy of the manifest in python.exe would
be sufficient, but frankly this should be py2exe's responsibility, not
yours or mine.
The change that I did means that we don't have to supplement Python's
manifest (or get them to change it) in order to also load the themeable
version of the comctl32 DLL. Prior to 2.6 we installed a .manifest file
because python.exe didn't have one (embedded or external) so there was
no conflict. Python 2.6 now has an embedded manifest that only
references the C runtime DLL, so it's not kosher to replace it and the
Python folks were reluctant to change it. So now wxPython supplements
it in code rather than in manifest, and things mostly work, but we're
obviously still working out the kinks.
> Do I need the msvcr*,msvcp* dlls in the
> same directory as the executable in order to remove the need for a
> manifest file? Some documentation here might help.
>
> 2) In one of my programs (again, "compiled" with py2exe), I am
> getting a strange debugging statement when running the executable from
> the command line:
>
> """
> 16:11:41: Debug: src/helpers.cpp(140): 'CreateActCtx' failed with
> error 0x000000
> 7b (the filename, directory name, or volume label syntax is
> incorrect.).
> """
>
Are you using the py2exe mode that embeds all the .pyd files or are they
still independent files? They may have to be independent files for the
code where I create the activation context to be able to work, please
try that.
Robin Dunn
> I really wish python 2.6.2 was compiled so that it didn't depend on
> the screwed up SxS Microsoft crap.
Me too, but IIUC then MS in their twisted wisdom has decreed that SxS is
the right way to do things and you can't even use the C runtime and
other DLLs designed for MSVC 9 without using either a local or global
assembly. So like usual their solution for a common problem was to make
more problems.
>
> Chris "frustrated" Spencer
Same here. My hairl-ine receded at least an inch so far while working
on this.
Robin Dunn
> in ubuntu 9.04 amd_64 I get this error:
> update-alternatives: unable to make
> /usr/lib/python2.6/site-packages/wx.pth.dpkg-tmp a symlink to
> /etc/alternatives/wx-python2.6.pth: No such file or directory
>
> any ideas?
> Thank you.
>
I've duplicated this and will try working on it this evening. Thanks
for reporting it.
Chris Spencer
requirement of my project. If you need me to split it out for testing
purposes, I can definitely TEST the theory, but in production I need a
single executable.
And thank you for clarifying the manifest file situation. It makes
sense that we'll still need the python manifest in the directory.
I still rue the day that Python 2.6 moved to the damned SxS DLL hell
we have now...
Chris.
On Mon, 18 May 2009 19:18:42 -0700, Robin Dunn <ro...@alldunn.com>
wrote:
r.liberda
> Jorge wrote:
>> in ubuntu 9.04 amd_64 I get this error:
>> update-alternatives: unable to make
>> /usr/lib/python2.6/site-packages/wx.pth.dpkg-tmp a symlink to
>> /etc/alternatives/wx-python2.6.pth: No such file or directory
>>
>> any ideas?
>> Thank you.
>>
>
> I've duplicated this and will try working on it this evening. Thanks
> for reporting it.
>
helped:
sudo cp -s /etc/alternatives/wx-python2.5.pth
/etc/alternatives/wx-python2.6.pth
after this, I could finish the installation
Rudolf
Jorge
I found that is a but in ubuntu 9.04:
http://www.mail-archive.com/univer...@lists.ubuntu.com/msg61584.html
I have to install 8.10, because I need to work.
cheers.
Jorge
Christopher Barker
> I am using the "single executable" mode, definitely. This is a
> requirement of my project. If you need me to split it out for testing
> purposes, I can definitely TEST the theory, but in production I need a
> single executable.
why is that? I agree that it is nice, but I've found that as soon as I
get beyond a trivial app, there is always SOMETHING else I need to
include. The MS dlls if nothing else.
Once you've got more than one file, what's a few hundred ;-)
You can put all the .py and .pyd files inside a directory to make things
a bit cleaner for your users.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Mike Driscoll
> Chris Spencer wrote:
>> I am using the "single executable" mode, definitely. This is a
>> requirement of my project. If you need me to split it out for testing
>> purposes, I can definitely TEST the theory, but in production I need a
>> single executable.
>
> why is that? I agree that it is nice, but I've found that as soon as I
> get beyond a trivial app, there is always SOMETHING else I need to
> include. The MS dlls if nothing else.
I was wondering that myself...
>
> Once you've got more than one file, what's a few hundred ;-)
>
> You can put all the .py and .pyd files inside a directory to make
> things a bit cleaner for your users.
>
> -Chris
>
I used to create just one executable, but then I found I had to include
some dlls and even then I had 1-2% of my users where the stupid
application wouldn't even run. I found if I didn't bundle it all into
one file, it suddenly started working. One of the py2exe guys told me
that he'd found single executables to be more problematic which I why I
dropped that.
If you need to distribute just one file, use Inno Setup to put all the
files into an installer. It's been working great for me for over a year.
Mike
Paul McNett
> Chris Spencer wrote:
>> I am using the "single executable" mode, definitely. This is a
>> requirement of my project. If you need me to split it out for testing
>> purposes, I can definitely TEST the theory, but in production I need a
>> single executable.
>
> why is that? I agree that it is nice, but I've found that as soon as I
> get beyond a trivial app, there is always SOMETHING else I need to
> include. The MS dlls if nothing else.
>
> Once you've got more than one file, what's a few hundred ;-)
>
> You can put all the .py and .pyd files inside a directory to make things
> a bit cleaner for your users.
INNO is also able to compress it significantly smaller when not in single-executable
mode, for some reason.
Paul
Robin Dunn
> I am using the "single executable" mode, definitely. This is a
> requirement of my project. If you need me to split it out for testing
> purposes, I can definitely TEST the theory, but in production I need a
> single executable.
Yes, please do test it.
Werner F. Bruhin
Robin Dunn wrote:
> Chris Spencer wrote:
>> I am using the "single executable" mode, definitely. This is a
>> requirement of my project. If you need me to split it out for testing
>> purposes, I can definitely TEST the theory, but in production I need a
>> single executable.
>
> Yes, please do test it.
I had tried 'bundle=1 and 2' and could not get it to work with Py2.6
(get what seems to be the "standard" error with SxS - app not correctly
installed), as I always use 'bundle=3' and create a "lib/library.zip" I
frankly did not try to hard.
The setup which works for me, generated on Vista and tested on XP is on
the wiki:
http://wiki.wxpython.org/py2exe
and the corresponding InnoSetup script is here:
http://wiki.wxpython.org/InnoSetup
Anyone please feel free to make comments on all these pages, there
definitely need some more work (hopefully next week), so if I get
comments that would be great.
Werner
Anthony Tuininga
> definitely need some more work (hopefully next week), so if I get comments
> that would be great.
FYI I have already worked around this annoying SxS problem on Windows
and Python2.6 with wxPython. I have been using wxPython with Python
2.6 on both Windows and Linux for some time now without any
difficulty. You can test it for yourself using the sample that is
provided with cx_Freeze (samples/wx). This is the correct link for
cx_Freeze (the one referenced in one of the pages is old)
http://cx-freeze.sourceforge.net
The sample setup.py looks as follows:
import sys
from cx_Freeze import setup, Executable
base = None
if sys.platform == "win32":
base = "Win32GUI"
setup(
name = "hello",
version = "0.1",
description = "Sample cx_Freeze wxPython script",
executables = [Executable("wxapp.py", base = base)])
Note that this is set up for both Windows and Linux. If you just want
Windows you can simplify as follows:
from cx_Freeze import setup, Executable
setup(
name = "hello",
version = "0.1",
description = "Sample cx_Freeze wxPython script",
executables = [Executable("wxapp.py", base = "Win32GUI")])
If you have any questions about this, let me know and I'd be happy to
answer them.
Anthony
Robin Dunn
>
> I do have a couple of questions, I remember I have already asked them
> but I probably didn't understand your answers. In the py2exe page, you
> mention the MS manifest. With Python 2.5, it's very easy to
> automatically generate a manifest, no special information is required.
> But as I am trying to understand how to support Python 2.6/Vista in
> GUI2Exe, I need to find a way to generate the manifest file or copy it
> from somewhere: can I just copy it from somewhere in the filesystem?
> If the answer is yes, from where? (I don't have Vista and I am
> explicitly avoiding the upgrade to Python 2.6).
One possibility is to extract the manifest from the python.exe or maybe
wxPython's _core_.pyd module (Py26 version in both cases) using ctypes.
There is an example of updating an embedded manifest here, you can
probably do something similar to extract a manifest:
http://trac.wxwidgets.org/browser/wxPython/tags/wxPy-2.8.9.2/wxPython/distrib/update_manifest.py
Andrea Gavana
I do have a couple of questions, I remember I have already asked them
but I probably didn't understand your answers. In the py2exe page, you
mention the MS manifest. With Python 2.5, it's very easy to
automatically generate a manifest, no special information is required.
But as I am trying to understand how to support Python 2.6/Vista in
GUI2Exe, I need to find a way to generate the manifest file or copy it
from somewhere: can I just copy it from somewhere in the filesystem?
If the answer is yes, from where? (I don't have Vista and I am
explicitly avoiding the upgrade to Python 2.6). Otherwise, where do I
get the Microsoft.VC90.CRT version and publicKeyToken numbers?
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
http://thedoomedcity.blogspot.com/
Werner F. Bruhin
Andrea Gavana wrote:
...
> I do have a couple of questions, I remember I have already asked them
> but I probably didn't understand your answers. In the py2exe page, you
> mention the MS manifest.
Take it all with a grain of salt, as I am definitely not an expert in
all this.
My current understanding/finding is that the appname.manifest is not
needed anymore as of 2.6 as Robin does this internally as of this
release. But it doesn't seem to hurt either if one still includes it.
In addition one needs the Microsoft.VC90.CRT.manifest file, one can
either install this and the corresponding dll's into a folder called
"Microsoft.VC90.CRT" in the app folder or just copy them next to the app
(the later works also on W2K), if one uses the py2exe option to store
things in a folder e.g. "lib" then a second copy needs to be copied to
this folder. BTW, if one uses InnoSetup to create the installer this is
no issue as it figures out that they are the same files and only
includes them once in the installer and on installation extracts them twice.
> With Python 2.5, it's very easy to
> automatically generate a manifest, no special information is required.
> But as I am trying to understand how to support Python 2.6/Vista in
> GUI2Exe, I need to find a way to generate the manifest file or copy it
> from somewhere: can I just copy it from somewhere in the filesystem?
> If the answer is yes, from where? (I don't have Vista and I am
> explicitly avoiding the upgrade to Python 2.6). Otherwise, where do I
> get the Microsoft.VC90.CRT version and publicKeyToken numbers?
>
I think Robin's suggestion of using ctypes to extract the manifest would
be the most elegant. I had a quick look at it and tried to adapt the
script to instead of updating to just "FindResource" but I can not make
it work - probably because this is way over my head.
Werner
Werner F. Bruhin
Anthony Tuininga wrote:
>> Anyone please feel free to make comments on all these pages, there
>> definitely need some more work (hopefully next week), so if I get comments
>> that would be great.
>>
>
> FYI I have already worked around this annoying SxS problem on Windows
> and Python2.6 with wxPython. I have been using wxPython with Python
> 2.6 on both Windows and Linux for some time now without any
> difficulty. You can test it for yourself using the sample that is
> provided with cx_Freeze (samples/wx). This is the correct link for
> cx_Freeze (the one referenced in one of the pages is old)
>
> http://cx-freeze.sourceforge.net
>
Only found it on the following page.
http://wiki.wxpython.org/CreatingStandaloneExecutables
Fixed it.
> The sample setup.py looks as follows:
>
> import sys
>
> from cx_Freeze import setup, Executable
>
> base = None
> if sys.platform == "win32":
> base = "Win32GUI"
>
> setup(
> name = "hello",
> version = "0.1",
> description = "Sample cx_Freeze wxPython script",
> executables = [Executable("wxapp.py", base = base)])
>
> Note that this is set up for both Windows and Linux.
When I "build" using the above for the samplewx.py script I used on for
the py2exe sample I get an exe and files in build\exe.win32-2.6 which
runs fine on my build machine.
However if I try to run it on my XP test machine I get the error "This
application has failed to start because the application configuration is
incorrect. Reinstalling the application may fix this problem.", but it
works fine if I try it on W2K.
I got it to work on the XP machine by adding the
"Microsoft.VC90.CRT.manifest" to the "build\exe.win32-2.6" folder (the
one I show on here http://wiki.wxpython.org/py2exe ).
Will try and write a page based on this for the wiki sometimes next week.
Werner
Anthony Tuininga
> Anthony,
>
> Anthony Tuininga wrote:
>>>
>>> Anyone please feel free to make comments on all these pages, there
>>> definitely need some more work (hopefully next week), so if I get
>>> comments
>>> that would be great.
>>>
>>
>> FYI I have already worked around this annoying SxS problem on Windows
>> and Python2.6 with wxPython. I have been using wxPython with Python
>> 2.6 on both Windows and Linux for some time now without any
>> difficulty. You can test it for yourself using the sample that is
>> provided with cx_Freeze (samples/wx). This is the correct link for
>> cx_Freeze (the one referenced in one of the pages is old)
>>
>> http://cx-freeze.sourceforge.net
>>
>
> Only found it on the following page.
> http://wiki.wxpython.org/CreatingStandaloneExecutables
>
> Fixed it.
Thanks.
>> The sample setup.py looks as follows:
>>
>> import sys
>>
>> from cx_Freeze import setup, Executable
>>
>> base = None
>> if sys.platform == "win32":
>> base = "Win32GUI"
>>
>> setup(
>> name = "hello",
>> version = "0.1",
>> description = "Sample cx_Freeze wxPython script",
>> executables = [Executable("wxapp.py", base = base)])
>>
>> Note that this is set up for both Windows and Linux.
>
> When I "build" using the above for the samplewx.py script I used on for the
> py2exe sample I get an exe and files in build\exe.win32-2.6 which runs fine
> on my build machine.
>
> However if I try to run it on my XP test machine I get the error "This
> application has failed to start because the application configuration is
> incorrect. Reinstalling the application may fix this problem.", but it works
> fine if I try it on W2K.
>
> I got it to work on the XP machine by adding the
> "Microsoft.VC90.CRT.manifest" to the "build\exe.win32-2.6" folder (the one I
> show on here http://wiki.wxpython.org/py2exe ).
Yes. You need to install the VC2008 redistributable or setup a private
assembly. That much cannot be changed. cx_Freeze took the default
approach that the redistributable has already been installed or can be
installed. The error message leaves a great deal to be desired but the
fault for that you can lay at Microsoft's feet. :-) Setting up a
private assembly as you did. To do that with cx_Freeze, use the
include_files option as in this:
includeFiles = [
("Microsoft.VC90.CRT.manifest", "Microsoft.VC90.CRT.manifest")
]
buildOptions = dict(
include_files = includeFiles)
setup(
name = "hello",
version = "0.1",
description = "Sample cx_Freeze wxPython script",
options = dict(build_exe = buildOptions),
executables = [Executable("wxapp.py", base = base)])
Hopefully that makes sense to you?
> Will try and write a page based on this for the wiki sometimes next week.
Sure. If you have questions at that point, let me know.
Anthony
werner
On 17/05/2009 22:19, Chris Spencer wrote:
....
> 2) In one of my programs (again, "compiled" with py2exe), I am
> getting a strange debugging statement when running the executable from
> the command line:
>
> """
> 16:11:41: Debug: src/helpers.cpp(140): 'CreateActCtx' failed with
> error 0x000000
> 7b (the filename, directory name, or volume label syntax is
> incorrect.).
> """
>
> It doesn't seem to affect the functioning of my program, but I just
> want to make sure I can ignore this and it won't bite me in the butt
> in the future.
>
Just seeing very similar error.
Using Python 2.5.4, wxPython 2.8.10.1, py2exe'd on Windows XP.
The application works fine as far as I can see and I only see this error
when running the "console" version, i.e. if I use the "windows" (py2exe)
option then nothing shows.
Error is above, but with different text (0x000007b (not enough storage
available to start process)
Has anyone found what the reason and resolution for this is?
Werner
Paul McNett
> wx.grid.Grid: Added methods CalcRowLabelsExposed,
> CalcColLabelsExposed, CalcCellsExposed, DrawRowLabels, DrawRowLabel,
> DrawColLabels, and DrawColLabel to the Grid class.
I've searched but I can't seem to find out the intended use case for
Grid.DrawColLabel() and Grid.DrawColLabels().
I was hoping they'd be a method of hooking into the drawing of the column headers so
I could draw to my own DC, but testing indicates that these methods are never
automatically called.
So they must be intended for custom calling by my code, but when would be the
appropriate place to call DrawColLabel(), so that the automatic drawing of the
headers doesn't override my custom drawing of the headers?
I'm basing this message on brief testing of 2.8.10.1 on Mac.
Thanks!
Paul
Robin Dunn
From Python you could use these methods when catching the label
windows' EVT_PAINT event. For example, if you wanted to have the
default look of the labels and then draw something extra on top of it
then you could bind EVT_PAINT, call one of the Draw*Label[s] methods and
then do your custom drawing.
Paul McNett
Thanks. Way back when, I tried catching EVT_PAINT and drawing my labels in the
PaintDC there, but there were cross-platform issues (segfaults, IIRC). I think I'll
give this a whirl again because the workaround I ended up with isn't pretty.
Paul
Robin Dunn
You may also want to look at the wx.lib.mixins.gridlabelrenderer module,
which makes it easy to plugin renderer object similar to how cell
renderers work.