I think it would help if you could provide a working example of this bug. Like a sip file which reproduces this behavior.
On Mon, Jul 11, 2011 at 7:12 AM, Tony Lynch <tly...@xype.com> wrote: > Hi Phil > > > > I’m using SIP to wrap a large C++ library and am very impressed with the > results so far – you’ve got an annotation for most of the use cases I’m > interested in. However, I think I’ve found a bug. I’ve copied in below my > own ‘description to self’ of the problem, if it is not sufficient for you to > see the problem then I’ll knock up a test case (let me know). > > > > When the wrapper for a class or one of its super classes indicates > 'virtual' for a method, a wrapper class is created in SIP called e.g. > sipIwBrep, that checks if the python instance has an override method for the > virtual call. If not then it calls what it thinks is the correct superclass > call. However, it's idea of the correct superclass call (in this case the > superclass being IwBrep) is actually calculated from the wrapper > declarations and it effectively finds the nearest superclass where the > relevant function is wrapped. In the case of this bug, IwObject was the > first superclass to have IsKindOf in the .sip file, so sipIwBrep was > incorrectly calling IwObject::IsKindOf instead of IwBrep::IsKindOf. > > > > I cannot see any reason why the SIP-produced subclass does not always call > the method on the immediate superclass (i.e. the wrapped class, in this case > IwBrep). > > > > I hope the above makes sense, > > Regards > > Tony > > _______________________________________________ > PyQt mailing list PyQt@riverbankcomputing.com > http://www.riverbankcomputing.com/mailman/listinfo/pyqt >
_______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt