In Qt, the event object are inherited from QEvent class for internal applications or things due to the application need to know about outside activities occur. Events can be received and processed by any QObject subclass instances, in particular widget. This document describes how to handle events and deliver in a typical application.
Transfer events
When an event occurs, Qt to create an event object (of the appropriate subclass QEvent), calls the event () method to be passed to QObject instances of complete transfer events.
event () method does not handle the event itself; it passes the event type, call the corresponding event handler, and a sentence is accepted or ignored event to issue a response.
Events can from the system (QmouseEvent and QKeyEvent); may be other sources (QTimerEvent); can be derived from the application itself.
Event Type
Most types of events has its specific category, such as common QResizeEvent, QPaintEvent, QMouseEvent, QKeyEvent and QCloseEvent. Each class is a subclass of QEvent and add event-specific functions. For example, QResizeEvent added size () and oldSize (), so that widgets can discover how they dimension is changed.
Some classes support multiple types of actual events. QMouseEvent support down the mouse button, double-click, move, and other related operations.
Each event type has an associated (:: type defined in QEvent), a convenient source of information as the type of running, you can quickly determine whether a given object is an event which is constructed from a subclass of.
Since the program needs to respond in a variety of complex ways, Qt event delivery mechanism is flexible. QCoreApplication :: notify () is a concise document describes the whole process; Qt Quarterly Another Look at Events not so succinctly discuss it again. Here, we will provide sufficient explanation 95% of applications.
Event Handler
After the usual method of passing event is to call a virtual function. For example, QPaintEvent by calling QWidget :: paintEvent () to pass. This virtual function is responsible for an appropriate response, usually through redrawn widgets. If you do not perform all the necessary work to achieve virtual functions, you may need to call the base class implementation.
For example, the following code processing from the left mouse button click on the check box widget defined, all other buttons simultaneously transmitted to the base click QCheckBox categories:
void MyCheckBox::mousePressEvent(QMouseEvent *event) { if (event->button() == Qt::LeftButton) { // handle left mouse button here } else { // pass on other buttons to base class QCheckBox::mousePressEvent(event); } }
If you want to replace the base class, you must implement all their own content. However, if you want to extend the functionality of the base class, you can achieve what you want, and to call the base class you do not want to deal with any situation get the default behavior.
Sometimes, there is no function to a specific event or function-specific event is not enough. The most common example is pressing the Tab key. Normally, QWidget intercept content to move the keyboard focus. But if the widgets themselves need the Tab key, you need the following method.
Now GM event handler can re-implement these objects QObject :: event (), or to perform event handling before or after conventional treatment, or completely replace the function. A very unusual small parts, which requires the Tab , but also a specific event in a custom application, it may contain the following event () function:
bool MyWidget::event(QEvent *event) { if (event->type() == QEvent::KeyPress) { QKeyEvent *ke = static_cast<QKeyEvent *>(event); if (ke->key() == Qt::Key_Tab) { // special tab handling here return true; } } else if (event->type() == MyCustomEventType) { MyCustomEvent *myEvent = static_cast<MyCustomEvent *>(event); // custom event handling here return true; } return QWidget::event(event); }
Note that for all outstanding cases, QWidget :: event () still is called, the return value indicates whether the processing of the event; to true value prevents event is sent to other objects.
Event Filter
Sometimes, an object needs to view and may be passed to intercept the event of another object. For example, the dialog is often desirable to filter certain button widget; e.g., modify the return key processing.
QObject :: installEventFilter () mounting an event filter, the filter is received in the event of the target object QObject :: eventFilter () in. Event filter processing events before processing the target object event, it is necessary to allow inspection and drop events. You can use QObject :: removeEventFilter () function deletes the existing event filter.
When you call the filter object eventFilter () implementation that can accept or reject events and allow further processing or reject events. If all the event filters allow further processing of the event (returns false), the event will be sent to the target object itself. If a stop processing (returns true), the target and any subsequent event filter can not see the event.
bool FilterObject::eventFilter(QObject *object, QEvent *event) { if (object == target && event->type() == QEvent::KeyPress) { QKeyEvent *keyEvent = static_cast<QKeyEvent *>(event); if (keyEvent->key() == Qt::Key_Tab) { // Special tab handling return true; } else return false; } return false; }
The above code shows another method for transmitting to a specific target knockdown widget Tab key press event. In the present embodiment, the filter processing related events and returns true, to prevent their further processing. All other events are ignored, the filter returns false, so as to transmit them to the target widgets installed in any other event filter thereon.
By mounting the filter in the event QCoreApplication QApplication or objects you can also filter all events the entire application. Such global event processing order of the filter in preference to a particular object event filter. It is very powerful, but it also reduces the overall application delivery speed event for each event; normally should use other techniques discussed.
Send event
Many applications want to create and send their own events. You can construct the appropriate event object and use QCoreApplication :: sendEvent () and QCoreApplication :: postEvent () to send events to send events to their event loop and Qt exactly the same way.
sendEvent () processes the event immediately. When it returns, the event filter and / or events have been processed, the object itself. For many event classes, there is a function called isAccepted (), which tells you whether the last call handler to accept or reject the event.
postEvent () will be posted to the event queue to be dispatched later. Qt's main event next time the loop runs, it dispatches all events have been published, and some optimization. For example, if there are multiple resize event, they are compressed into one. The same applies to paint events: QWidget :: update () call postEvent (), which eliminates flicker by avoiding multiple redrawing and speed.
To create a custom type of event, you need to define an event number that must be greater than QEvent :: User, and you need to subclasses QEvent in order to pass specific information on custom events. For more information, see QEvent documentation.