wysota, thanks for your reply.
This is because the thread object lives in the main thread and not the thread it represents. Thus if you emit a signal connected to the quit() slot, the call is queued so that it can be executed in the main thread. But since you call wait() in the main thread, the slot never has a chance to execute because the main thread is already locked by wait().
I still do not understand why, since the QThread has its own event loop and since I move myObject to the thread, so I change its thread affinity, the events launched by myObject are handled by the event loop of the main thread and not by the event loop of the thread the object belongs to.
A solution is to either not call wait() at all (as it is not required) and instead simply connect the finished() signal to the deleteLater() slot
I need to wait the thread effectively finishes because I need to do some operations only after the thread has been stopped. I did not write them on the example code for simplicity reasons.
not call wait() in the onStopClicked() slot but instead connect a custom slot to the finished() signal and call wait() from that slot.
that could work, but consider the following case where I need to stop the thread when the application is closed
{
myObject->stop();
}
void MainDialog::waitForOpFinished()
{
myObject->wait();
/* ..... */
}
void MainDialog::closeEvent(QCloseEvent *ce)
{
myObject->stop();
}
void MainDialog::waitForOpFinished()
{
myObject->wait();
/* ..... */
}
To copy to clipboard, switch view to plain text mode
I can not perform a wait on another slot, because since the application is being closed that slot could not be called
Bookmarks