QEvent and notify()
-
I hear from someone that is not recommended to use notify() in events and recommended to use post and send methods. So the questions is why it's not recommended ? And what the difference between send, post and notify ?
-
In short form:
- QCoreApplication::sendEvent send a syncronous event and process it directly
- QCoreApplication::postEvent send an asyncronous event and process it duriong a following event loop run
- QCoreApplication::notify handler that directly puts the event to the object. This is used internally if you use send or post event to dispatch the event.
from the docs:
-
"QCoreApplication::sendEvent":http://qt-project.org/doc/qt-4.8/qcoreapplication.html#sendEvent
[quote] Sends event event directly to receiver receiver, using the notify() function. Returns the value that was returned from the event handler.
The event is not deleted when the event has been sent. The normal approach is to create the event on the stack[/quote] -
"QCoreApplication::postEvent":http://qt-project.org/doc/qt-4.8/qcoreapplication.html#postEvent
[quote]
Adds the event event, with the object receiver as the receiver of the event, to an event queue and returns immediately.
The event must be allocated on the heap since the post event queue will take ownership of the event and delete it once it has been posted. It is not safe to access the event after it has been posted.
When control returns to the main event loop, all events that are stored in the queue will be sent using the notify() function.[/quote]
- "QCoreApplication::notify":http://qt-project.org/doc/qt-4.8/qcoreapplication.html#notify
[quote]
Sends event to receiver: receiver->event(event). Returns the value that is returned from the receiver's event handler. Note that this function is called for all events sent to any object in any thread.
For certain types of events (e.g. mouse and key events), the event will be propagated to the receiver's parent and so on up to the top-level object if the receiver is not interested in the event (i.e., it returns false).
There are five different ways that events can be processed; reimplementing this virtual function is just one of them. All five approaches are listed below:
Reimplementing paintEvent(), mousePressEvent() and so on. This is the commonest, easiest and least powerful way.
Reimplementing this function. This is very powerful, providing complete control; but only one subclass can be active at a time.
Installing an event filter on QCoreApplication::instance(). Such an event filter is able to process all events for all widgets, so it's just as powerful as reimplementing notify(); furthermore, it's possible to have more than one application-global event filter. Global event filters even see mouse events for disabled widgets. Note that application event filters are only called for objects that live in the main thread.
Reimplementing QObject::event() (as QWidget does). If you do this you get Tab key presses, and you get to see the events before any widget-specific event filters.
Installing an event filter on the object. Such an event filter gets all the events, including Tab and Shift+Tab key press events, as long as they do not change the focus widget.
[/quote]
-
Ok, thanks, Gerolf. One more question: is it possible to post or send event from one thread to other ? And if it possible describe how ?
-
It is possible and it is simple:
QCoreApplication::postEvent :-)
You specify an object pointer for the receiver object. The thread affinity of the object defines where it will be processed. -
It is actually the mechamism behind cross-thread signals and slots. However, only use QCoreApplication::postEvent, not the sendEvent variant.