On Wed, 03 Jun 2009 22:57:32 +0200, Vicente Sole <[email protected]> wrote: > Quoting Darren Dale: > >> On Wed, Jun 3, 2009 at 2:40 PM, Darren Dale <[email protected]> wrote: >> >> One last point, however: I think Armando's suggestion of passing the >> object, >> and not the object's id(), coupled with Phil's patch, is the right >> solution: >> > > At my side, passing the object was already fine on 64-bit without > Phil's patch. It is under 32-bit that the check has to be made. > > If I have understood Phil's patch, it tries to set a long into an > unsigned 32bit. Darren has already found it does not work under 64 bit > for the case of passing the address of the object. > > Since Trolltech already decided not to fix their bug, I would just > leave the things as they are concerning PyQt. The alternative of > passing the object works as it should in most cases. The cases where > retrieving the object address via the call to internalID() fail are > easy to catch because at the python side one receives a negative > number when one is expecting a positive number and it can be converted > as in the example I sent previously. > > createIndex can accept a pointer or a quint32 so, in any case one > would say it is a positive number. Perhaps forcing the return of > internalId() to be a quint64 instead of qint64 in > qabstractitemmodel.sip could do the job, but then we would not be > respecting the (incorrect) Qt API. > > So, unless I get I successful test under 32-bit with Phil\'s patch, I > would just leave the things as they are.
Except that this keeps coming up. Does changing the type of internalId() from qint64 to quint64 solve the problem (I don't have a 32 bit Linux system handy)? Phil _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
