ANN: wxPython 2.8.10.1

Robin · May 17, 2009, 5:31am

Announcing

···

----------

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

Mario_Lacunza · May 17, 2009, 6:12am

Hello Robin,

Great! but there are a version for Ubuntu 9.04 amd64?

Thanks!

Mario

···

2009/5/17 Robin Dunn robin@alldunn.com

Announcing

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

wxpython-users mailing list

wxpython-users@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

Christoph_Willing · May 17, 2009, 9:46am

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:
InstallingOnUbuntuOrDebian - wxPyWiki

···

On 17/05/2009, at 4:12 PM, Mario Lacunza wrote:

2009/5/17 Robin Dunn <robin@alldunn.com>
Announcing
----------

The 2.8.10.1 release of wxPython is now available for download at
Redirecting.... 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
Index of /cairo

--
Robin Dunn
Software Craftsman
http://wxPython.org

_______________________________________________
wxpython-users mailing list
wxpython-users@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
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

Chris_Spencer1 · May 17, 2009, 8:19pm

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? 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.

Alix_Al · May 17, 2009, 8:30pm

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.

···

On Sun, May 17, 2009 at 10:46 AM, Christoph Willing cwilling@users.sourceforge.net wrote:

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 robin@alldunn.com

Announcing

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

wxpython-users mailing list

wxpython-users@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

wxpython-users@lists.wxwidgets.org

http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

wxpython-users mailing list

wxpython-users@lists.wxwidgets.org

http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

Werner_F_Bruhin1 · May 18, 2009, 7:27am

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).

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_Spencer1 · May 18, 2009, 12:36pm

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.

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.bruhin@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

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

Werner_F_Bruhin1 · May 18, 2009, 1:56pm

Chris,

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

driscollis · May 18, 2009, 2:19pm

Werner F. Bruhin wrote:

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

Blog: http://blog.pythonlibrary.org

Werner_F_Bruhin1 · May 18, 2009, 4:42pm

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'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

driscollis · May 18, 2009, 9:13pm

Werner F. Bruhin wrote:

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_Spencer1 · May 18, 2009, 9:22pm

What Python version are you using?

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

···

On Mon, 18 May 2009 15:56:03 +0200, "Werner F. Bruhin" <werner.bruhin@free.fr> wrote:

Chris,

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

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

Robin · May 19, 2009, 2:18am

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?

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
Software Craftsman

Robin · May 19, 2009, 2:19am

Chris Spencer wrote:

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
Software Craftsman

Robin · May 19, 2009, 2:19am

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.

···

--
Robin Dunn
Software Craftsman

Chris_Spencer1 · May 19, 2009, 5:34am

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.

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 <robin@alldunn.com> wrote:

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.

r.liberda · May 19, 2009, 9:33am

Robin Dunn schrieb:

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.

in ubuntu-9.04-desktop-i386 I get the same error. A workaround for me helped:
sudo cp -s /etc/alternatives/wx-python2.5.pth /etc/alternatives/wx-python2.6.pth
after this, I could finish the installation

Rudolf

Alix_Al · May 19, 2009, 10:24am

Rudolf,
I found that is a but in ubuntu 9.04:
http://www.mail-archive.com/universe-bugs@lists.ubuntu.com/msg61584.html

I have to install 8.10, because I need to work.

cheers.

Jorge

···

On Tue, May 19, 2009 at 10:33 AM, r.liberda r.liberda@gmx.at wrote:

Robin Dunn schrieb:

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.

in ubuntu-9.04-desktop-i386 I get the same error. A workaround for me helped:

sudo cp -s /etc/alternatives/wx-python2.5.pth /etc/alternatives/wx-python2.6.pth

after this, I could finish the installation

Rudolf

wxpython-users mailing list

wxpython-users@lists.wxwidgets.org

http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

Chris_Barker1 · May 19, 2009, 5:08pm

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.

-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

Chris.Barker@noaa.gov

driscollis · May 19, 2009, 5:23pm

Christopher Barker 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.

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