On Wednesday September 24 2003 10:04, Patrick Stinson wrote:
> in progression:
> Does the %ConvertToSubClassCode directive require some sort of
> class identification mechanism to be written into the original
> cpp library code? QEvent returns an enumerated value in
> type(), as well ass QApplication and some others, and QObject
> has QObject::className() that returns a string identifier.
> that can be used in conjuction with sipMapStringToClass() and
> a sipStringTypeClassMap struct.
> Does this mean I have to modify my cpp library to add some
> sort of class identifier for classs/subclasses if I want
> polymorphic return values in my python functions?
I had the same question, but unfortunately I posted it to Phil
twice rather once to him and once to the list. Here's our
exchange:
On Monday 22 September 2003 4:47 pm, you wrote:
> On Monday September 22 2003 02:03, Phil Thompson wrote:
> > > media = PK.CreateMediaLayer("./track.ogg")
> > > while not media.AtEnd():
> > > media.Read()
> >
> > What do you get when you "print media"? If you get a
> > PK_MediaLayer instance then maybe you haven't implemented
> > %ConvertToSubClassCode properly.
===== my post =======
> From copying PyQt code, I understand (I think) how to implement
> %ConvertToSubClassCode for hierarchies like QObject or QEvent -
> but those both have methods that return some kind of type
> identifier (like QObject::className() ).
>
> If a hierarchy of classes *doesn't* have a method like that,
> how do you do the %ConvertToSubClassCode block? Use the C++
> RTTI typeid() function?
> eg:
> class A {};
> class B : public A {};
> ---
> %HeaderCode
> #include <typeinfo>
> %End
> %ConvertToSubClassCode
> static sipStringTypeClassMap map[] = {
> {sipName_B, &sipClass_B},
> ...
> };
> sipClass = sipMapStringToClass(
> typeid (*sipCpp),
> map, sizeof (map)/sizeof (map[0]));
> %End
> Would that work? I'm assuming sipCpp is already of the
> subclass' type (or sipCpp->className () wouldn't work?), and
> this is just fixing the corresponding PyObject's type?
===== Phil's reply =======
There are potential problems there because the C++ instance might
be "QObject" or "sipQObject", but that's just a case of setting
the table up properly. It doesn't really matter how it is
implemented, so long as a valid PyObject * is returned that is
actually a Python class object.
_______________________________________________
PyKDE mailing list [EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
