wxPython / SWIG questions

James_Carroll1 · April 3, 2005, 1:15am

Hello,

I'm taking my first stab at wrapping some wxWidgets C++ with wxPython
-aware SWIG. I'm having trouble including the right .i files from my
.i file.

python: 2.5.4.1 with Robin's wxWidgets lib and includes. I think it's
missing the .py files from the
wxPython-2.5.4.1\include\wx\wxPython\i_files directory, so I copied
those in from the wxWidgets/wxPython/src directory in wxWidgets head
CVS. (hoping they're not too different.)

SWIG: latest + robin's patches compiled with MinGW.
I'm compiling with VC++ 6.0

I've gotten pretty far, I created a DLL sucessfully, and imported it,
but when I tried to pass it a python string as for a wxString
parameter, it complained it couldn't convert. So now I'm trying to
include the right .i files so that swig sees the wxPython definitions.

My .i file looks like:

%define DOCSTRING
"Zoomable image reader for Zoomify format"
%enddef

%module(package="bright", docstring=DOCSTRING) zoomify

%{
#include "imaging/big/ZoomableImageReader.h"
#include "imaging/big/zoomifyReaderWx.h"
%}

%import windows.i
%import controls.i
%pythoncode { import wx }

class ZoomifyReaderWx
{
public:
%pythonAppend ZoomifyReaderWx "self._setOORInfo(self)"

bool Open(wxString filename);
void Close();
...

And the erros I get look like:

erforming Custom Build Step on ..\..\..\src\imaging\big\zoomifyReaderWx.i
..\..\..\libs\wxPython-2.5.4.1\include\wx\wxPython\i_files\_window.i(734):
Warning(302): Identifier 'PopupMenuXY' redefined (ignored) (Renamed
from 'PopupMenu'),
..\..\..\libs\wxPython-2.5.4.1\include\wx\wxPython\i_files\_window.i(733):
Warning(302): previous definition of 'PopupMenuXY' (Renamed from
'PopupMenu').
Compiling...
zoomifyReaderWx.cpp
zoomifyReaderWx_wrap.cpp
C:\jimc\bright\samples\wxPyHybrid\pyZoominfy\gen\zoomifyReaderWx_wrap.cpp(1562)
: error C2065: 'wxString_in_helper' : undeclared identifier
C:\jimc\bright\samples\wxPyHybrid\pyZoominfy\gen\zoomifyReaderWx_wrap.cpp(1562)
: error C2440: 'initializing' : cannot convert from 'int' to 'class
wxString *'
Conversion from integral type to pointer type requires
reinterpret_cast, C-style cast or function-style cast
C:\jimc\bright\samples\wxPyHybrid\pyZoominfy\gen\zoomifyReaderWx_wrap.cpp(1568)
: error C2065: 'wxPyBeginAllowThreads' : undeclared identifier

How can I figure out what I haven't included?

Thanks!
-Jim

James_Carroll1 · April 3, 2005, 1:40am

Okay, I almost have it... I changed my .i file to include the C++
wxpython.h, and it's compiling, and starting to work! Now, it's
having trouble decoding jpegs. My interactive console looks like
this:

C:\jimc\bright\samples\wxPyHybrid\pyZoominfy\gen>python -i -c "import zoomify"

import wx
wx.InitAllImageHandlers()
reader = zoomify.ZoomifyReaderWx()
f = reader.Open("c:\\jimc\\My Pictures\\Slides\\sg.pff")
reader.GetWidth()

11472

t = reader.GetTile(5,5,0)

20:35:44: Warning: No image handler for type image/jpeg defined.

and my working .i looks like:

%define DOCSTRING
"Zoomable image reader for Zoomify format"
%enddef

%module(package="bright", docstring=DOCSTRING) zoomify

%{
#include "wx/wxPython/wxPython.h"
#include "wx/wxPython/pyclasses.h"

#include "imaging/big/ZoomableImageReader.h"
#include "imaging/big/zoomifyReaderWx.h"
%}

%import core.i
%pythoncode { import wx }

class ZoomifyReaderWx
{
public:
bool Open(wxString filename);
void Close();

Thanks!
-Jim

···

On Apr 2, 2005 8:15 PM, James Carroll <mrmaple@gmail.com> wrote:

Hello,

I'm taking my first stab at wrapping some wxWidgets C++ with wxPython
-aware SWIG. I'm having trouble including the right .i files from my
.i file.

python: 2.5.4.1 with Robin's wxWidgets lib and includes. I think it's
missing the .py files from the
wxPython-2.5.4.1\include\wx\wxPython\i_files directory, so I copied
those in from the wxWidgets/wxPython/src directory in wxWidgets head
CVS. (hoping they're not too different.)

SWIG: latest + robin's patches compiled with MinGW.
I'm compiling with VC++ 6.0

I've gotten pretty far, I created a DLL sucessfully, and imported it,
but when I tried to pass it a python string as for a wxString
parameter, it complained it couldn't convert. So now I'm trying to
include the right .i files so that swig sees the wxPython definitions.

My .i file looks like:

%define DOCSTRING
"Zoomable image reader for Zoomify format"
%enddef

%module(package="bright", docstring=DOCSTRING) zoomify

%{
#include "imaging/big/ZoomableImageReader.h"
#include "imaging/big/zoomifyReaderWx.h"
%}

%import windows.i
%import controls.i
%pythoncode { import wx }

class ZoomifyReaderWx
{
public:
    %pythonAppend ZoomifyReaderWx "self._setOORInfo(self)"

    bool Open(wxString filename);
    void Close();
...

And the erros I get look like:

erforming Custom Build Step on ..\..\..\src\imaging\big\zoomifyReaderWx.i
..\..\..\libs\wxPython-2.5.4.1\include\wx\wxPython\i_files\_window.i(734):
Warning(302): Identifier 'PopupMenuXY' redefined (ignored) (Renamed
from 'PopupMenu'),
..\..\..\libs\wxPython-2.5.4.1\include\wx\wxPython\i_files\_window.i(733):
Warning(302): previous definition of 'PopupMenuXY' (Renamed from
'PopupMenu').
Compiling...
zoomifyReaderWx.cpp
zoomifyReaderWx_wrap.cpp
C:\jimc\bright\samples\wxPyHybrid\pyZoominfy\gen\zoomifyReaderWx_wrap.cpp(1562)
: error C2065: 'wxString_in_helper' : undeclared identifier
C:\jimc\bright\samples\wxPyHybrid\pyZoominfy\gen\zoomifyReaderWx_wrap.cpp(1562)
: error C2440: 'initializing' : cannot convert from 'int' to 'class
wxString *'
        Conversion from integral type to pointer type requires
reinterpret_cast, C-style cast or function-style cast
C:\jimc\bright\samples\wxPyHybrid\pyZoominfy\gen\zoomifyReaderWx_wrap.cpp(1568)
: error C2065: 'wxPyBeginAllowThreads' : undeclared identifier

How can I figure out what I haven't included?

Thanks!
-Jim

James_Carroll1 · April 3, 2005, 11:59am

What am I seing? First: I figured out that I needed to use wxselect
to make sure I was using the right version of wxwidgets (I had 255
installed, and my extension uses 2541 dll linkage) But It's not
perfect yet.

my reader.GetTile returns a wxImage * that it creates decoding a jpeg
stream. When I call it, I get a PySwigObject instead of something
that I can treat like a wxImage.

import wxversion
wxversion.select("2.5.4")
import wx
wx.__version__

'2.5.4.1'

import zoomify
reader = zoomify.ZoomifyReaderWx()
reader.Open("C:/jimc/My Pictures/Slides/sg.pff")

True

reader.GetWidth()

11472

t = reader.GetTile(5,5,0)
dir(t)

t

t.SaveFile("C:/jimc/out.png", wx.BITMAP_TYPE_PNG)

Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'PySwigObject' object has no attribute 'SaveFile'

The SWIG documentation tells me that returning a pointer to an object
that SWIG knows about should work, and my .i file does include core.i
which in turn includes _image.i, which holds wxImage declarations.

How can I coerece <Swig Object at _1089f600_p_wxImage> into
<wx._core.Image; proxy of C++ wxImage instance at
_b01d8601_p_wxImage>??

Chris: I'm mostly the tutorial here:
Yahooist Teil der Yahoo Markenfamilie and
looking at the SWIG Doc/manual/python.html page, and some of Robin's
examples like wxPython/contrib/gizmos. If I can put together an
example of a visual c project that 'just works' I'll write it up.

Floatcanvas looks sweet. If I can figure out how to write these
extensions, I'll probably be writing a few simpler renderers myself.
If things really start making sense, I'll wrap a renderer that use the
AntiGrainGeometry library on a wxPanel. (someday) I like how it
worked out for Matplotlib.

···

On Apr 3, 2005 2:42 AM, Chris Barker <Chris.Barker@noaa.gov> wrote:

James Carroll wrote:
> Okay, I almost have it... I changed my .i file to include the C++
> wxpython.h, and it's compiling, and starting to work!

Jim,

I'm sorry I can't help you with this, you are way ahead of me. However,
I'm very interested in how this works out, and would like to help.
Please let me know when you've got something working.

By the way, did you check out FloatCanvas? From what I can tell, with a
few of the kind of optimizations that you are working on, it might meet
you needs very well. At the moment, it doesn't have a grid feature, but
I would like to add that, as I need it as well.

-Chris

Robin · April 3, 2005, 11:50pm

James Carroll wrote:

t = reader.GetTile(5,5,0)
dir(t)

t

<Swig Object at _1089f600_p_wxImage>

t.SaveFile("C:/jimc/out.png", wx.BITMAP_TYPE_PNG)

Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'PySwigObject' object has no attribute 'SaveFile'

The SWIG documentation tells me that returning a pointer to an object
that SWIG knows about should work, and my .i file does include core.i
which in turn includes _image.i, which holds wxImage declarations.

Take a look at the C code for the GetTile wrapper, that might give some hints.

Starting with 1.3.24 SWIG has a new scheme for sharing the runtime type info between modules. It actually stores it in just one place and it is accessed from a special Python module that the extension modules import to get their reference to that table. SWIG also allows the name of the type table to be renamed in order to reduce conflits if there are types from multiple modules that have the same name, so I've given the table that wxPython uses a custom name. If you are not specifying this name then I think it would manifest as what you are seeing: the runtime doesn't know enough about wxImage to construct a proxy for it. Add the following #define to your compile options to set the name:

-DSWIG_TYPE_TABLE=wxPython_type_table

If you already have that then there must be some other problem...

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

James_Carroll1 · April 4, 2005, 2:10am

Thanks Robin,

Take a look at the C code for the GetTile wrapper, that might give some
hints.

Hmmm... It looks like it's aware of wxImage as a SWIG type (because of
the SWIGTYPE_p_wxImage) ... but it's keeping it as a SWIG pointer, and
not a wxPython wx.Image. I'm not sure if this is right or not.

···

---------------------------------------------------
The generated C++:

        result = (wxImage *)(arg1)->GetTile(arg2,arg3,arg4);

        wxPyEndAllowThreads(__tstate);
        if (PyErr_Occurred()) SWIG_fail;
    }
    resultobj = SWIG_NewPointerObj((void*)(result), SWIGTYPE_p_wxImage, 0);
    return resultobj;
    fail:
    return NULL;
}

---------------------------------------------------
Here's (most of) my .i file:

%define DOCSTRING
"Zoomable image reader for Zoomify format"
%enddef

%module (package="mbf", docstring=DOCSTRING) zoomify

%{
#include "wx/wxPython/wxPython.h"
#include "wx/wxPython/pyclasses.h"

#include "imaging/big/zoomifyReaderWx.h"
%}

%import core.i

class ZoomifyReaderWx
{
public:
bool Open(wxString filename);
void Close();

ZoomifyReaderWx();
%pragma(python) addtomethod = "__init__:self._setOORInfo(self)"

    // necessary for ZoomableImageReader
    virtual int GetWidth(int reduction = 0);
    virtual int GetHeight(int reduction = 0);
    wxImage* GetTile(unsigned int x, unsigned int y, unsigned int reduction);
};

%init %{
wxClassInfo::CleanUpClasses();
wxClassInfo::InitializeClasses();
%}

I know that something is going right, because if I don't import core.i
then when I do a file Open, it can't change the python string to a
wxString. The above does typemap the python str to wxString.

------------------------------------------
My test script:

import wxversion
wxversion.select("2.5.4")
import wx
print "version %s" % (wx.__version__)
import zoomify

reader = zoomify.ZoomifyReaderWx()
reader.Open("C:/jimc/My Pictures/Slides/sg.pff")
print "width is %i " % reader.GetWidth()
tile = reader.GetTile(5,5,0)
tile.SaveFile("C:/jimc/tile.png", wx.BITMAP_TYPE_PNG)

------------------------------------------
Gives me the result:

version 2.5.4.1
width is 11472
Traceback (most recent call last):
File "test.py", line 12, in ?
tile.SaveFile("C:/jimc/tile.png", wx.BITMAP_TYPE_PNG)
AttributeError: 'PySwigObject' object has no attribute 'SaveFile'

My VC6 release project has the following defines:

SWIG_TYPE_TABLE=wxPython_type_table,NDEBUG,WIN32,__WIN32__,
_WINDOWS,_MBCS,_USRDLL,PYZOOMIFY_EXPORTS,WXUSINGDLL,_DLL

I changed the code generation of my DLL to Multithreaded DLL to avoid
some missing symbols during linking.

does anyone else have a swig 1.3.24 + patches / wxpython 2.5.4.1
extension that's working that I could see?

Thanks,
-Jim

Starting with 1.3.24 SWIG has a new scheme for sharing the runtime type
info between modules. It actually stores it in just one place and it is
accessed from a special Python module that the extension modules import
to get their reference to that table. SWIG also allows the name of the
type table to be renamed in order to reduce conflits if there are types
from multiple modules that have the same name, so I've given the table
that wxPython uses a custom name. If you are not specifying this name
then I think it would manifest as what you are seeing: the runtime
doesn't know enough about wxImage to construct a proxy for it. Add the
following #define to your compile options to set the name:

-DSWIG_TYPE_TABLE=wxPython_type_table

If you already have that then there must be some other problem...

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Robin · April 4, 2005, 5:27pm

James Carroll wrote:

Thanks Robin,

Take a look at the C code for the GetTile wrapper, that might give some
hints.

Hmmm... It looks like it's aware of wxImage as a SWIG type (because of
the SWIGTYPE_p_wxImage) ...

There is a difference between knowing the name of the type and being able to create an instance of it. It will make a SWIGTYPE_p_wxImage just from seeing it used as a return value. But if it can't find an entry in the types table that includes the function to call to make a new instance then it can't make one.

but it's keeping it as a SWIG pointer, and
not a wxPython wx.Image. I'm not sure if this is right or not.

---------------------------------------------------
The generated C++:

        result = (wxImage *)(arg1)->GetTile(arg2,arg3,arg4);
                wxPyEndAllowThreads(__tstate);
        if (PyErr_Occurred()) SWIG_fail;
    }
    resultobj = SWIG_NewPointerObj((void*)(result), SWIGTYPE_p_wxImage, 0);
    return resultobj;
    fail:
    return NULL;
}

You'll probably have to trace into SWIG_NewPointerObj to see why it is failing to create the proxy object. Also look at how swig_type_list_handle is initialized in the module's init function.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

James_Carroll1 · April 5, 2005, 4:32pm

Hi Robin, I tried again on another system with VC7.1 instead of VC6
just to see if anything would change... No luck.

There is a difference between knowing the name of the type and being
able to create an instance of it. It will make a SWIGTYPE_p_wxImage
just from seeing it used as a return value. But if it can't find an
entry in the types table that includes the function to call to make a
new instance then it can't make one.

Where do you define the types table? Is it in the .i files?

You'll probably have to trace into SWIG_NewPointerObj to see why it is
failing to create the proxy object.

I'll have to build a debug version of python (python23_d.lib) for the
stepping & debugging, I'll try this weeked.

Also look at how
swig_type_list_handle is initialized in the module's init function.

Using some printfs I know that

swig_type_list_handle =
SWIG_Python_LookupTypePointer(swig_type_list_handle);

Is the code that is getting compiled ( I don't have SWIG_LINK_RUNTIME
or SWIG_STATIC_RUNTIME defined).

That doesn't tell me much though.

Thanks for your time Robin,

Does it look like I'm doing everything right? Do you know of anyone
using your 2.5.4.1 .i files to do something similar (which would tell
me I probably can fix this?)

-Jim

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Robin · April 6, 2005, 2:31am

James Carroll wrote:

Hi Robin, I tried again on another system with VC7.1 instead of VC6
just to see if anything would change... No luck.

There is a difference between knowing the name of the type and being
able to create an instance of it. It will make a SWIGTYPE_p_wxImage
just from seeing it used as a return value. But if it can't find an
entry in the types table that includes the function to call to make a
new instance then it can't make one.

Where do you define the types table? Is it in the .i files?

SWIG builds it. It's done in this bit of code in the init function:

         for (i = 0; swig_types_initial[i]; i++) {
             swig_types[i] = SWIG_TypeRegister(swig_types_initial[i]);
         }

which basically populates the types table (swig_type_list_handle) with the swig_type_info structures that it doesn't already know about, and saves a local copy of the pointer. So if the swig_type_list_handle was initialized from the shared table then it will just be adding new types to the existing table, but if it couldn't get the shared table for some reason then it will just make a new one.

You'll probably have to trace into SWIG_NewPointerObj to see why it is
failing to create the proxy object.

I'll have to build a debug version of python (python23_d.lib) for the
stepping & debugging, I'll try this weeked.

Also look at how
swig_type_list_handle is initialized in the module's init function.

Using some printfs I know that

swig_type_list_handle =
SWIG_Python_LookupTypePointer(swig_type_list_handle);

Is the code that is getting compiled ( I don't have SWIG_LINK_RUNTIME
or SWIG_STATIC_RUNTIME defined).

That doesn't tell me much though.

You'll want to trace into this too, or just add printf's to it since it's located in the same file.

Thanks for your time Robin,

Does it look like I'm doing everything right? Do you know of anyone
using your 2.5.4.1 .i files to do something similar (which would tell
me I probably can fix this?)

wxMozilla is a 3rd-party extension module that is also using SWIG.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

James_Carroll1 · April 6, 2005, 10:37am

It Works!

After looking at wxMozilla's .i file and seing that they include
typemaps instead of core, and then reading:
Typemaps

I see that somehow I'm missing a typemap(out) wxImage*, so in
my_typemaps.i I see that there's no wxImage... but there is an
ImageList, etc. So I add

%typemap(out) wxImage* { $result =
wxPyMake_wxObject($1, $owner); }

to my .i file, and it works! Thanks for having such an easy
Make_wxObject function.

Yeay!

Would you want to:

i_files/my_typmaps.i
%typemap(out) wxImageList* { $result =
wxPyMake_wxObject($1, $owner); }
+%typemap(out) wxImage* { $result =
wxPyMake_wxObject($1, $owner); }
%typemap(out) wxListItem* { $result =
wxPyMake_wxObject($1, $owner); }

Or do you want to keep just what you need for wxPython in your .i files?

Thanks,
-Jim

···

On Apr 5, 2005 10:31 PM, Robin Dunn <robin@alldunn.com> wrote:

James Carroll wrote:
> Hi Robin, I tried again on another system with VC7.1 instead of VC6
> just to see if anything would change... No luck.
>
>
>>There is a difference between knowing the name of the type and being
>>able to create an instance of it. It will make a SWIGTYPE_p_wxImage
>>just from seeing it used as a return value. But if it can't find an
>>entry in the types table that includes the function to call to make a
>>new instance then it can't make one.
>
>
> Where do you define the types table? Is it in the .i files?

SWIG builds it. It's done in this bit of code in the init function:

         for (i = 0; swig_types_initial[i]; i++) {
             swig_types[i] = SWIG_TypeRegister(swig_types_initial[i]);
         }

which basically populates the types table (swig_type_list_handle) with
the swig_type_info structures that it doesn't already know about, and
saves a local copy of the pointer. So if the swig_type_list_handle was
initialized from the shared table then it will just be adding new types
to the existing table, but if it couldn't get the shared table for some
reason then it will just make a new one.

>
>
>>You'll probably have to trace into SWIG_NewPointerObj to see why it is
>>failing to create the proxy object.
>
>
> I'll have to build a debug version of python (python23_d.lib) for the
> stepping & debugging, I'll try this weeked.
>
>
>>Also look at how
>>swig_type_list_handle is initialized in the module's init function.
>
>
> Using some printfs I know that
>
> swig_type_list_handle =
> SWIG_Python_LookupTypePointer(swig_type_list_handle);
>
> Is the code that is getting compiled ( I don't have SWIG_LINK_RUNTIME
> or SWIG_STATIC_RUNTIME defined).
>
> That doesn't tell me much though.

You'll want to trace into this too, or just add printf's to it since
it's located in the same file.

>
> Thanks for your time Robin,
>
> Does it look like I'm doing everything right? Do you know of anyone
> using your 2.5.4.1 .i files to do something similar (which would tell
> me I probably can fix this?)

wxMozilla is a 3rd-party extension module that is also using SWIG.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Robin · April 6, 2005, 5:33pm

James Carroll wrote:

Would you want to:

i_files/my_typmaps.i
%typemap(out) wxImageList* { $result =
wxPyMake_wxObject($1, $owner); }
+%typemap(out) wxImage* { $result =
wxPyMake_wxObject($1, $owner); }
%typemap(out) wxListItem* { $result =
wxPyMake_wxObject($1, $owner); }

Or do you want to keep just what you need for wxPython in your .i files?

I'll add it.

I still wonder though why SWIG wasn't at least making a new isntance for it. The wxPyMake_wxObject is really only needed when a class heirarchy hides the real type of a return value. For example when a function returns a wxWindow* but the real type of the object is a wxButton*. The default behavior of SWIG in that case woudl have been to create a new wx.Window instance that would refer to the same C++ object, but for some reason that is not working for you with wxImage...

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

James_Carroll1 · April 6, 2005, 6:02pm

returns a wxWindow* but the real type of the object is a wxButton*. The
default behavior of SWIG in that case woudl have been to create a new
wx.Window instance that would refer to the same C++ object, but for some
reason that is not working for you with wxImage...

I'm just elated that it works.

One more question:

When I link my extension against your 2541 libs, I have a dependancy
on those specific libraries... but I've never come across a project
that has you download a different binary package for every dot release
of the versions of python extensions that it relies on.

Is it possible to have my wxPython-aware extensions work with all
binary compatable (2.5.x) installs? When I try my extension in
2.5.5-pre, I see: "this application has faild to start" looking for
wxmsw254h_vc.dll. This is just an academic question, I'll be using
py2exe to distribute anything, and that will include the specific
dlls.

-Jim

···

On Apr 6, 2005 1:33 PM, Robin Dunn <robin@alldunn.com> wrote:

James Carroll wrote:

>
> Would you want to:
>
> i_files/my_typmaps.i
> %typemap(out) wxImageList* { $result =
> wxPyMake_wxObject($1, $owner); }
> +%typemap(out) wxImage* { $result =
> wxPyMake_wxObject($1, $owner); }
> %typemap(out) wxListItem* { $result =
> wxPyMake_wxObject($1, $owner); }
>
> Or do you want to keep just what you need for wxPython in your .i files?

I'll add it.

I still wonder though why SWIG wasn't at least making a new isntance for
it. The wxPyMake_wxObject is really only needed when a class heirarchy
hides the real type of a return value. For example when a function
returns a wxWindow* but the real type of the object is a wxButton*. The
default behavior of SWIG in that case woudl have been to create a new
wx.Window instance that would refer to the same C++ object, but for some
reason that is not working for you with wxImage...

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Robin · April 6, 2005, 6:20pm

James Carroll wrote:

One more question:

When I link my extension against your 2541 libs, I have a dependancy
on those specific libraries... but I've never come across a project
that has you download a different binary package for every dot release
of the versions of python extensions that it relies on.

Is it possible to have my wxPython-aware extensions work with all
binary compatable (2.5.x) installs?

By definition the 2.5 series is *not* binary compatible because the APIs are allowed to change. The 2.6 series will maintain binary compatibility so it should be possible there. See http://wiki.wxpython.org/index.cgi/ReleaseSeries

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!