types across multiple modules

Ok, I have read many past messages about multiple module projects and 
the adventures they can cause. Well I too have to go down that path and 
am learning as well about the strange behaviors. So here is the 
apparently simple problem.

I have a library at the core which defines various objects. This 
library has been working for months extremely well. I now want to 
create a second module that uses the objects created in module 1. 
Interestingly I can use them as input parameters and the system works, 
but as return parameters I get the dreaded opaque pointer strings.

So given the following simple example.

So in module one, I have a factory method to return an instance of a 
class, say CreateObject().  Inside the wrapper file, this gets 
implemented as:

static PyObject *_wrap_CreateObject__SWIG_0(PyObject *self, PyObject 
*args) {
    PyObject *resultobj;
    OE::Object *result;
    PyObject * obj0  = 0 ;

    if(!PyArg_ParseTuple(args,(char *)"|O:CreateObject",&obj0)) goto 
fail;
    if (obj0) {
        arg1 = (unsigned int) PyInt_AsLong(obj0);
        if (PyErr_Occurred()) SWIG_fail;
    }
    result = (OE::Object *)CreateObject(arg1);

    resultobj = SWIG_NewPointerObj((void *) result, 
SWIGTYPE_p_OE__Object, 1);
    return resultobj;
    fail:
    return NULL;
}

then in module 2 I have one method that take an object pointer and 
returns and integer handle and a second that takes an integer handle 
and returns an object pointer.  Oddly, the first method works, 
returning a valid handle, but the second doesn't.  So here is how the 
second method is implemented in module 2's wrapper file:

static PyObject *_wrap_DerefHandle(PyObject *self, PyObject *args) {
    PyObject *resultobj;
    int arg1 ;
    OE::Object *result;

    if(!PyArg_ParseTuple(args,(char *)"i:OEDerefHandle",&arg1)) goto 
fail;
    result = (OE::Object *)OEDerefHandle(arg1);

    resultobj = SWIG_NewPointerObj((void *) result, 
SWIGTYPE_p_OE__Object, 0);
    return resultobj;
    fail:
    return NULL;
}

notice that in both of these the SWIG_NewPointerObj call is casting to 
the same SWIG type and in the second instance, as expected, SWIG is not 
handing ownership to Python.

So if I compile these modules with the '-c' flag, link them with 
libswigpy, all as recommended in the manual, this is the result.

# example

from module1 import *
from module2 import *

obj = CreateObject()
print obj

handle = GetHandle(obj)
print handle

newobj = DerefHandle(handle)
print newobj


gives this result (note that the handle value is valid, so I know the 
GetHandle method is doing the type checking correctly and is working:

<C Object instance at _006e6f08_p_OE__Object>
-100
_006e6f08_p_OE__Object

I also note the pointer address of the returned object is the same as 
the original, so I am close, but exceedingly confused.

Any ideas?

Thanks
Bob

Robert W. Tolbert  Ph.D.                        p. (505) 473-7385
OpenEye Scientific Software                     f. (505) 473-0833
3600 Cerrillos Road, Suite 1107
Santa Fe, NM 87507

_______________________________________________
Swig maillist  -  Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig