[PyQt] Qt or PyQt problem?
Phil Thompson
phil at riverbankcomputing.com
Wed Jun 3 22:14:59 BST 2009
On Wed, 03 Jun 2009 22:57:32 +0200, Vicente Sole <sole at esrf.fr> wrote:
> Quoting Darren Dale:
>
>> On Wed, Jun 3, 2009 at 2:40 PM, Darren Dale <dsdale24 at gmail.com> 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
More information about the PyQt
mailing list