[C++-sig] Re: Using .add_property with make_getter.

[David Abrahams]

Kirsebom Nikolai <nikolai.kirsebom at siemens.no> writes:

>> From: David Abrahams [mailto:dave at boost-consulting.com]
>> 
>> Kirsebom Nikolai <nikolai.kirsebom at siemens.no> writes:
>> 
>> >
>> > I have a converter for converting CString <--> python string.
>> > See code in thread "Exception second time loaded" 20th of June.
>> >
>> > The two attributes are exposed with the statements:
>> > 	.def_readonly("UserID", &PyDLEPRInterface::m_UserID)
>> > and
>> > 	.add_property("DocumentCategory",
>> > make_getter(&PyDLEPRInterface::m_DocumentCategory,
>> > return_value_policy<return_by_value>()))
>> >
>> > When running in Python, the UserID is available 
>> 
>> What does "available" mean?
>
> Only that I'm able to read it's value from Python.


Near as I can tell, your problem is that there is no CString ->
Python string conversion registered.  Have you wrapped functions
which return CString objects?

>> > however reading the DocumentCategory attribute produces the
>> > following traceback:
>> >
>> > import DocuLive  #<<Module exposing function to get an existing
>> > PyDELEPRInterface object
>> > import CString #<<Module handling the conversion
>> > v = DocuLive.getit() #<<Fetch the exisiting object
>> > v.UserID #<<Print the value for UserID attribute
>> > 44
>> > v.DocumentCategory 
>> > Traceback (most recent call last):
>> >   File "<input>", line 1, in ?
>> > TypeError: bad argument type for built-in operation
>> 
>> Can you post a complete, minimal test case that we can use to
>> reproduce the problem?
>> 
>
> I'll try to make a test-case.  

Thanks.

> Problem with the current system is that it
> includes a lot of propriatory code  that I cannot provide.
>
>> > I'm running the python statements in a PyCrust (wxPython/wxWindows)
>> > shell application.  In my posting 20th of June I asked for help
>> > relating to exception when staring the second time.  It appears that
>> > the starting of the mainloop in the PyCrust application produces the
>> > exception if other applications (in Windows) has been activated in
>> > between.  
>> 
>> I don't know what that means, but I can tell you that if you want to
>> initialize the same Boost.Python extension modules a 2nd time, the
>> Boost.Python DLL must be unloaded first.  I don't know what it takes
>> to do that, but I'm guessing we have a problem because it gets
>> referenced by each of the BPL extension modules which is loaded, and
>> they in turn are being kept alive because no PyFinalize() is being
>> called, because we don't support PyFinalize() yet.  Dirk Gerrits has
>> been working on a solution, but has been waylaid.  It's an important
>> feature to get implemented, but Boost Consulting has to focus on
>> projects which have been funded.
>
> What code actually initiates the Boost.Python initialization ?  

Nothing explicit; it's initialized on most systems as soon as the
first Boost.Python extension module is loaded.

> My extension DLL is not unloaded, at least when running in the
> debugger (VS 7.0) the Modules windows lists the DLLs (Python22.dll,
> boost_python_debug.dll and DLEPRPythonDld.dll (mine)).
>
> I enclose my 'module' file.  Maybe the solution is obvious to someone.  I'll
> be away for some time and I'll look into making a 'workable' test-case when
> back.  Untill then, thanks for your quick reply and help.

My pleasure.

> PS: Could the problem (getting access to the property) be related to the
> fact that I wrap the actual instance object in a new class PyDLEPRInterface
> inheriting from DLEPRInterface, something I had to do because of compiler
> error (see my posting on the 20th of June (Exception second time loaded). 

Yep.  The make_getter call doesn't know anything about the
relationship between PyDLEPRInterface and DLEPRInterface, so it can't
know that it's legit for the first argument to be a PyDLEPRInterface
object.  Try:

    Whatever PyDLEPRInterface::*doc_category
       = &PyDLEPRInterface::m_DocumentCategory;

    ...

        .add_property(
           "DocumentCategory",
            make_getter(
               doc_category, return_value_policy<return_by_value>()
            )
         )

Instead.

> PPS: The CPythonDocuLiveDlg dialog is executed with the DoModal().
>
> PPPS: I've not been able to retreive the exception information when the
> statement "wxPython.lib.PyCrust.PyShellApp.main()" fails.  So I've made a
> counter to indicate where the it failed, an 'i' comes out with the value 2.
>

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com