QObject::event() return value vs. QEvent::setAccepted()
-
Both the return value of QObject::event() and the accepted state of QEvent seems to indicate whether the event has been consumed or if the event may be propagated to a parent object (correct me if I am wrong!). What is the difference? Is there anything that can be accomplished with the QObject::event() return value that can't be accomplished with the accept state? (I may have misunderstood everything, please enlighten me...)
-
Most event handlers don't have a result value, so QEvent::setAccepted() is required for that. Mucking with the accept state in QObject::event() probably is bad practice, as event() is the function that delegates the QEvents to the proper handlers. In the end you can ignore the accept state in the event() function if you really need to.
-
Each QObject fiters the events of other objects. Best practice would be you get the event of your QObject and handle it the way you need it.
-
[quote author="Jakob Schou" date="1297868973"]Both the return value of QObject::event() and the accepted state of QEvent seems to indicate whether the event has been consumed or if the event may be propagated to a parent object (correct me if I am wrong!). What is the difference? Is there anything that can be accomplished with the QObject::event() return value that can't be accomplished with the accept state? (I may have misunderstood everything, please enlighten me...)[/quote]
See http://doc.qt.nokia.com/qq/qq11-events.html#acceptorignore :)
-
Thanks. The link posted by peppe above explains how it works:
"The "accept" flag is a communication mechanism between the specific event handlers and event(), whereas the bool return value of event() is used to communicate with QApplication::notify()."
So basically the default event() method will "convert" the "accept" flag to its return value.