Qt-interest Archive, May 2007
Re: What's wrong with Qt4.3.0beta compiler?
Message 1 in thread
Scott Aron Bloom wrote:
>do you derive from qobject first?
>-Scott
>
>
>
Yes, the first class roots at QTreeWidget
class TreeParser : public XbelTree, public MdiAbstract
class XbelTree : public TreeWidget
class TreeWidget : public QTreeWidget, public cNOTIFIER_RECEIVER
Thanks,
Lingfa
--
[ signature omitted ]
Message 2 in thread
On 04.05.07 10:53:51, Lingfa Yang wrote:
> Scott Aron Bloom wrote:
>
> >do you derive from qobject first? -Scott
> >
> >
> Yes, the first class roots at QTreeWidget
>
> class TreeParser : public XbelTree, public MdiAbstract
> class XbelTree : public TreeWidget
> class TreeWidget : public QTreeWidget, public cNOTIFIER_RECEIVER
And the first line in TreeParser as well as XbelTree is the Q_OBJECT
macro?
Andreas
--
[ signature omitted ]
Message 3 in thread
Andreas Pakulat wrote:
>On 04.05.07 10:53:51, Lingfa Yang wrote:
>
>
>>Scott Aron Bloom wrote:
>>
>>
>>
>>>do you derive from qobject first? -Scott
>>>
>>>
>>>
>>>
>>Yes, the first class roots at QTreeWidget
>>
>>class TreeParser : public XbelTree, public MdiAbstract
>>class XbelTree : public TreeWidget
>>class TreeWidget : public QTreeWidget, public cNOTIFIER_RECEIVER
>>
>>
>
>And the first line in TreeParser as well as XbelTree is the Q_OBJECT
>macro?
>
>Andreas
>
>
>
Andreas, Thank you for your help.
I checked my code. It turns TreeParser class does not have Q_OBJECT,
and its two first parents XbelTree and TreeWidget do have the macro.
TreeParser has no any signal/slot stuff, do you mean I have to add OBJECT and moc it?
Lingfa
--
[ signature omitted ]
Message 4 in thread
>>
>> And the first line in TreeParser as well as XbelTree is the Q_OBJECT
>> macro?
>>
>> Andreas
>>
>>
>>
> Andreas, Thank you for your help.
>
> I checked my code. It turns TreeParser class does not have Q_OBJECT,
> and its two first parents XbelTree and TreeWidget do have the macro.
> TreeParser has no any signal/slot stuff, do you mean I have to add
> OBJECT and moc it?
> Lingfa
>
And the first line in TreeParser as well as XbelTree is the Q_OBJECT
macro?
Problem solved, and thanks everyone for discussion.
To conclude, one point is that Qt4.3.0beta performs more check in
"qobject_cast", where the first parent class must not only derive from
QObject always, but also MUST use Q_OBJECT and moc it, which doesn’t
matter whether or not signal/slot are used. The previous versions are
not that strict on the last point.
Again, thanks everyone.
Lingfa
--
[ signature omitted ]
Message 5 in thread
> -----Original Message-----
> From: Lingfa Yang [mailto:lingfa@xxxxxxx]
> Sent: Friday, May 04, 2007 9:47 AM
> To: qt-interest@xxxxxxxxxxxxx
> Cc: qt-interest@xxxxxxxxxxxxx
> Subject: Re: What's wrong with Qt4.3.0beta compiler?
>
>
> >>
> >> And the first line in TreeParser as well as XbelTree is the
Q_OBJECT
> >> macro?
> >>
> >> Andreas
> >>
> >>
> >>
> > Andreas, Thank you for your help.
> >
> > I checked my code. It turns TreeParser class does not have Q_OBJECT,
> > and its two first parents XbelTree and TreeWidget do have the macro.
> > TreeParser has no any signal/slot stuff, do you mean I have to add
> > OBJECT and moc it?
> > Lingfa
> >
> And the first line in TreeParser as well as XbelTree is the Q_OBJECT
> macro?
>
> Problem solved, and thanks everyone for discussion.
>
> To conclude, one point is that Qt4.3.0beta performs more check in
> "qobject_cast", where the first parent class must not only derive from
> QObject always, but also MUST use Q_OBJECT and moc it, which doesn't
> matter whether or not signal/slot are used. The previous versions are
> not that strict on the last point.
>
> Again, thanks everyone.
> Lingfa
Good to hear that you tracked this down. I really suggest that you send
this info to support@trolltech, as this change will effect many
people..... I have done that many times as well, derive from QObject
for the parent/child memory management, but at the base class, no
sigs/slots so no Q_OBJECT...
Scott
--
[ signature omitted ]
Message 6 in thread
>Good to hear that you tracked this down. I really suggest that you send
>this info to support@trolltech, as this change will effect many
>people..... I have done that many times as well, derive from QObject
>for the parent/child memory management, but at the base class, no
>sigs/slots so no Q_OBJECT...
I would have agreed with you but it's documented to require Q_OBJECT
macro (at least in 4.2.2)
T qobject_cast ( QObject * object )
Returns the given object cast to type T if the object is of type T (or of a
subclass); otherwise returns 0.
The class T must inherit (directly or indirectly) QObject and be declared
with the Q_OBJECT macro.
--
[ signature omitted ]
Message 7 in thread
Hi,
> To conclude, one point is that Qt4.3.0beta performs more check in
> "qobject_cast", where the first parent class must not only derive from
> QObject always, but also MUST use Q_OBJECT and moc it, which doesn’t
> matter whether or not signal/slot are used. The previous versions are
> not that strict on the last point.
They actually *are* that strict: qobject_cast may fail silently if Q_OBJECT is
omitted, even in Qt 4.2 and earlier. Thanks to the new compile-time check in
Qt 4.3, qobject_cast won't fail silently anymore.
--
[ signature omitted ]
Message 8 in thread
Hi,
> To conclude, one point is that Qt4.3.0beta performs more check in
> "qobject_cast", where the first parent class must not only derive from
> QObject always, but also MUST use Q_OBJECT and moc it, which doesn't
> matter whether or not signal/slot are used. The previous versions are
> not that strict on the last point.
They actually *are* that strict: qobject_cast may fail silently if Q_OBJECT is
omitted, even in Qt 4.2 and earlier. Thanks to the new compile-time check in
Qt 4.3, qobject_cast won't fail silently anymore.
--
[ signature omitted ]
