[type] custom values must be >= 65536?

[Boy]

Hi,

the Qt Assistant claims that when creating custom items, the type id of the items (in Qt3 this was called RTTI) have to be equal or greater than 65536.

But after debugging my program after a crash, I came to notice that 65536 is used by QGraphicsItem. I was using this ID for a custom item and caused the crash.

Shouldn't it be great than 65536, without the equal in the Qt assistant?

[wysota]

QGraphicsItem is a pure virtual class so this id will never be returned for QGraphicsItem. As for the crash, I suggest you show us the backtrace from the debugger.

[Boy]

QGraphicsItem is a pure virtual class so this id will never be returned for QGraphicsItem. As for the crash, I suggest you show us the backtrace from the debugger.

Yep, it is, but I'll describe you the situation.

the concerning class inherits from QAbstractGraphicsShapeItem. This class only requires implementation of the boundingRect() and paint(). I haven't implemented the 'type()' function here, so it'll call its base class type() function. QAbstractGraphicsShapeItem inherits QGraphicsItem and calls its type() function returning 65536.

I used 65536 as offset of my custom items, so my items are

65536 + 0 --> equal to QGraphicsItem
65536 + 1
65536 + 2
...

This is where it goes wrong. I think you shouldn't use 65536, but only values greater than it. I increased the offset with 1 and now the issue is gone.

Therefore my opinion is that the Qt Assistant is wrong...

[wysota]

You will never have an instance of QGraphicsItem, therefore you'll never experience a clash with this particular class. If you want to differenciate from all subclasses of QGraphicsItem that do not reimplement type(), you have to return a different number, of course. But in theory there is nothing wrong in returning QGraphicsItem::UserType. Be aware of the fact that reimplementing type() is not enough. You also have to define the Type enum as noted in the docs. Maybe that's why you experience crashes.

[Boy]

You will never have an instance of QGraphicsItem, therefore you'll never experience a clash with this particular class. If you want to differenciate from all subclasses of QGraphicsItem that do not reimplement type(), you have to return a different number, of course. But in theory there is nothing wrong in returning QGraphicsItem::UserType. Be aware of the fact that reimplementing type() is not enough. You also have to define the Type enum as noted in the docs. Maybe that's why you experience crashes.
hmm...still think it's weird...
in the documentation it also states 'UserType + 1' in the enum for the first type. UserType is defined as 65536. So in the example code fragment it states '65536 + 1'.

Actually, what I mean is, that you are not allowed to create an own type and make it return 65536 (== UserType) as Type.

So you shouldn't forget to reimplement type() for custom items and therefore QGraphicsItem::type() should be pure virtual

[wysota]

Actually, what I mean is, that you are not allowed to create an own type and make it return 65536 (== UserType) as Type.
Why not? If you don't reimplement type() that is what is going to happen. And qgraphicsitem_cast() will work fine, only that it will not know your class and it will report objects of your class as QGraphicsItems.


So you shouldn't forget to reimplement type() for custom items and therefore QGraphicsItem::type() should be pure virtual

I don't agree. What if you don't use the information anywhere? The default value is fine then.

[Boy]

Ok...I think I now understand what you mean...In case you don't need to know what the exact type is of the item, the default (UserType) is fullfills, as Qt only needs to know that it is a QGraphics-based item.

Only in case MY OWN software needs to know for some purpose (as it is in my case) the precise item, I should implement type(), but still, I should use a nr > UserType, to distinguish it from the baseclass ... correct?

[wysota]

Only in case MY OWN software needs to know for some purpose (as it is in my case) the precise item, I should implement type(), but still, I should use a nr > UserType, to distinguish it from the baseclass ... correct?

Correct. Otherwise you won't be able to tell between your items and items that return the default value.

[Boy]

Correct. Otherwise you won't be able to tell between your items and items that return the default value.

Ok...it's clear now..thanks for your time!