How does accept work in QWidget::closeEvent() ?
-
In documentation:
@QWidget Class
void QWidget::closeEvent(QCloseEvent * event) [virtual protected]@
You can reimplement this function to change the way the widget responds to window close requests:
@void MainWindow::closeEvent(QCloseEvent *event)
{
if (maybeSave()) {
writeSettings();
event->accept();
} else {
event->ignore();
}
}@
In C++, QWidget::closeEvent() in the base class is no longer called when the function is redefined in the derived class. I would like to understand who is actually closing the window in case of event->accept(), so please tell me what you think. -
Hi,
what means "I would like to have some idea about who is actually closing the window in case of event->accept()" ??
-
The documentation says that QWidget::closeEvent() closes the widget when the accept flag is on. But now that QWidget::closeEvent() is overwritten it will never be called. So what function and through what mechanism does actually close that widget?
[quote author="mcosta" date="1366268986"]Hi,
what means "I would like to have some idea about who is actually closing the window in case of event->accept()" ??
[/quote] -
Hi,
The doc also says "By default, the event is accepted and the widget is closed."
The default implementation of closeEvent is:
@void QWidget::closeEvent(QCloseEvent *event)
{
event->accept();
}
@When QWidget::close() is called, an event is send and the result of it being accepted or refused makes the operation go further or not. If you want all the gory details you'll have to read Qt's sources.
-
Right, so closeEvent does not actually close the widget, it only decides whether to close the widget or not. Some other function is triggered by the event and closes the widget.
Do you know what is the relation between events and signals? It seems to me that signals are special types (wrappers) of events, but I am not sure.
Thank you for your answer.
[quote author="SGaist" date="1366272791"]Hi,
The doc also says "By default, the event is accepted and the widget is closed."
The default implementation of closeEvent is:
@void QWidget::closeEvent(QCloseEvent *event)
{
event->accept();
}
@When QWidget::close() is called, an event is send and the result of it being accepted or refused makes the operation go further or not. If you want all the gory details you'll have to read Qt's sources.[/quote]
-
Have a look at the "Events and filters":http://qt-project.org/doc/qt-4.8/eventsandfilters.html as well as "Signals and slots":http://qt-project.org/doc/qt-4.8/signalsandslots.html documentation.
You'll have a better understanding of how things work
-
Right, thank you.
http://qt-project.org/doc/qt-4.8/signalsandslots.html
"A signal is emitted when a particular event occurs."
So a signal is like an internal Qt event.
Of course, events are also internal Qt events:
http://qt-project.org/doc/qt-4.8/eventsandfilters.html
"When an event occurs, Qt creates an event object to represent it by constructing an instance of the appropriate QEvent subclass"
Qt Events wrap window server events, I suppose.
[quote author="SGaist" date="1366273698"]Have a look at the "Events and filters":http://qt-project.org/doc/qt-4.8/eventsandfilters.html as well as "Signals and slots":http://qt-project.org/doc/qt-4.8/signalsandslots.html documentation.You'll have a better understanding of how things work[/quote]
-
I know it's a bit confusing but no, it's not like an internal Qt Event:
bq. Signals are emitted by an object when its internal state has changed in some way that might be interesting to the object's client or owner. Only the class that defines a signal and its subclasses can emit the signal
However the signal emission can be the result of an event that as happened (i.e. the signal clicked() of a QPushButton)
-
Very well, thank you. So signals have their own mechanism, different from the events' mechanism.
[quote author="SGaist" date="1366275880"]I know it's a bit confusing but no, it's not like an internal Qt Event:
[/quote]