The contents of this chapter are also about QT events. Perhaps this chapter can not have a complete example, because the event always feel very abstract, or from the bottom of the understanding of the better!
Before we talk about the role of events, let's look at how we can receive events. Recalling the previous code, we overridden the event function in the subclass to allow these subclasses to do what we need, just like the following code:
voidMylabel::mousepressevent (Qmouseevent *Event)
{
if(Event->button () = = Qt::leftbutton) {
//Do something
}Else{
Qlabel::mousepressevent (Event);
}
}
The above code is similar to the previous, detected in the mouse down event, if the left button is pressed, do our work, if not left, then call the parent class function. This, in a way, is to pass the event up to the parent class to respond, i.e. we "ignore" the event in the subclass.
We can think of the Qt event pass as a chain: if the subclass does not handle the event, it will continue to pass to the other classes. In fact, the event object for Qt has an accept () function and a ignore () function. As their name says, the former is used to tell Qt that the event handler "receives" the event and does not pass it, while the latter tells Qt that the event handler "ignores" the event and needs to continue passing to find another recipient. In the event handler function, you can use isaccepted () to query whether the event has been received.
In fact, we seldom use the accept () and ignore () functions, but like the example above, if you want to ignore the event, just call the parent class's response function. Remember we once said that the events in Qt are mostly protected, so that the overridden function must have a response function in its parent class, and this method is feasible. Why did you do it? Because we cannot confirm that this handler function in the parent class has no action, if we ignore the event directly in the subclass, QT will not look for other recipients, then the parent class will not be able to do so, which can potentially be dangerous. Also, let's look at the implementation of Qwidget's Mousepressevent () function:
voidQwidget::mousepressevent (Qmouseevent *Event)
{
Event->ignore ();
if((windowtype () = = Qt::P opup)) {
Event->accept ();
qwidget* W;
while((w = qapp->activepopupwidget ()) && W! = This){
W->close ();
if(Qapp->activepopupwidget () = = W)//widget does not want to dissappear
W->hide ();//Hide at least
}
if(!rect (). Contains (Event->pos ())) {
Close ();
}
}
}
Note that the first statement, if all subclasses do not overwrite the Mousepressevent function, is ignored here, suggesting that the component does not care about the event, which could be passed to its parent component.
However, things are not absolute. In one case, we have to use the accept () and ignore () functions, that is, when the window is closed. If you need to have a query dialog when the window is closed, you need to write this:
voidMainwindow::closeevent (Qcloseevent *Event)
{
if(Continuetoclose ()) {
Event->accept ();
}Else{
Event->ignore ();
}
}
BOOLMainwindow::continuetoclose ()
{
if(Qmessagebox::question ( This,
Tr"Quit"),
Tr"is sure to quit this application?"),
Qmessagebox::yes | Qmessagebox::no,
Qmessagebox::no)
= = Qmessagebox::yes) {
return true;
}Else{
returnfalse;
}
}
This way, we are asked to exit the program normally.
"Go" event receive and ignore