Details
-
Bug
-
Resolution: Invalid
-
P2: Important
-
None
-
5.4.0
-
None
-
CentOS Linux release 7.0.1406 (Core). KDE: 4.10.5.
Description
Here's a simple example.
header:
class myApp : public QObject { Q_OBJECT public: explicit myApp(QObject *parent = 0) {} public slots: void startApp(const QString &); void catchFinished(int, QProcess::ExitStatus); };
source:
void myApp::startApp(const QString &app) { QProcess *process = new QProcess(); connect(process.data(), SIGNAL(finished(int, QProcess::ExitStatus)), SLOT(catchFinished(int, QProcess::ExitStatus))); process->start(app); process->waitForStarted(); process->terminate(); } void myApp::catchFinished(int exit, QProcess::ExitStatus exitStatus) { qDebug() << "Signal caught"; }
Forget the obvious memory leak for now since this is only a simple example for proof of bug. The catchFinished slot never gets called. In fact, the ONLY time it ever gets called is if I add this function below the terminate:
process->waitForFinished();
This makes the signal itself way less useful if I'm having to set up artificial blocking of the code anyways... Also, this does NOT capture when I close the application outside of my Qt program (ex: starting firefox, then closing firefox by clicking the "x" at the top right). This is the most frustrating part of this bug. Not even the stateChanged signal is emitted when closed outside of the program.
The only workaround I can think of is to start up the QProcess in it's own running thread, and call waitForFinished() within the thread immediately after I start the process... I'd prefer not to use a hack like this, and just have Qt be able to track when the process is running, and call finished() when it's closed, just like how it's documented.
Thank you.