[PyQt] Qt or PyQt problem?
"V. Armando Solé"
sole at esrf.fr
Thu Jun 4 07:35:52 BST 2009
Phil Thompson wrote:
> On Wed, 03 Jun 2009 22:57:32 +0200, Vicente Sole wrote:
>> 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)?
No, it does not.
With your patch and changing the returned value of internalId() to
quint32 I got it working on 32-bit for both cases, that means, when
passing the object and when passing the address of the object. So, I
guess internalId() should return an unsigned int32 in a 32-bit platform
and an unsigned int64 in a 64-bit platform.
Changing qabstractitemmodel.sip from:
qint64 internalId() const;
unsigned long internalId() const;
gives correct results for the object case under the platforms I can test.
For the value case, it works under 32-bit but most likely will fail
under 64-bit when the written number cannot be represented by a 32-bit
I do not know if my "unsigned long" patch can have side effects on other
platforms. It makes sense that if one passes an object and the address
of the object is stored, one should get back an unsigned of the type the
machine is using for addresses. I always thought it is unsigned long,
but perhaps there are more exotic solutions around. Is it possible to
modify qabstractitemmodel.sip set the returned value as quint32 on
32-bit platforms and quint64 on 64-bit platforms? That should solve the
issue I am finding without (hopefully) introducing new ones.
More information about the PyQt