QProcess disconnect trouble

[wally]

It depends on what your process does. If it has a systray icon, then it must have an event loop.

Understandable. But the QProcess that is running is not necessarily in the Systray. The program that calls the QProcess runs in the systray.

Eitherway, the signals on the QProcess do not get disconnected. I tested connecting/disconnecting signals from other random objects (like a spinbox) and that works fine.

I'm starting to think that the signals of a QProcess that has an active process cannot be disconnected while the process is still running.

[squidge]

Have you tried blockSignals ?

[wally]

Yup. See post #6

Didn't work either.

[norobro]

Maybe it's a windows/vs problem. You might try your app on Linux or do somethiing simple like the following to see if it works:

I created a new GUI project with Qt Creator. Used your code in the MainWindow constructor to start a process (a php script that waits for input on stdin) and make connections, put a push button in the form, and created two slots:

void MainWindow::on_pushButton_clicked(){
    disconnect(process,SIGNAL(error(QProcess::ProcessError)),0,0);
    process->kill();
}
 
void MainWindow::handleProcessError(QProcess::ProcessError){
    qDebug() << process->errorString();
}

void MainWindow::on_pushButton_clicked(){
    disconnect(process,SIGNAL(error(QProcess::ProcessError)),0,0);
    process->kill();
}

void MainWindow::handleProcessError(QProcess::ProcessError){
    qDebug() << process->errorString();
}

To copy to clipboard, switch view to plain text mode 

It silently kills the process as shown. If I comment out the disconnect statement I get "Process crashed".

[wally]

Maybe it's a windows/vs problem. You might try your app on Linux or do somethiing simple like the following to see if it works:

I created a new GUI project with Qt Creator. Used your code in the MainWindow constructor to start a process (a php script that waits for input on stdin) and make connections, put a push button in the form, and created two slots:

void MainWindow::on_pushButton_clicked(){
    disconnect(process,SIGNAL(error(QProcess::ProcessError)),0,0);
    process->kill();
}
 
void MainWindow::handleProcessError(QProcess::ProcessError){
    qDebug() << process->errorString();
}

void MainWindow::on_pushButton_clicked(){
    disconnect(process,SIGNAL(error(QProcess::ProcessError)),0,0);
    process->kill();
}

void MainWindow::handleProcessError(QProcess::ProcessError){
    qDebug() << process->errorString();
}

To copy to clipboard, switch view to plain text mode 

It silently kills the process as shown. If I comment out the disconnect statement I get "Process crashed".

Hmmm.. Maybe it is a Windows problem since that's essentially what I tried.

What version of Qt are you using?

I will try this in Linux and/or QtCreator tomorrow.

[ChrisW67]

From post 7:

disconnect(process, SIGNAL(error(QProcess::ProcessError)), 0, 0);
disconnect(process, SIGNAL(finished(int exitCode, QProcess::ExitStatus)), 0,0);
process->kill();

disconnect(process, SIGNAL(error(QProcess::ProcessError)), 0, 0);
disconnect(process, SIGNAL(finished(int exitCode, QProcess::ExitStatus)), 0,0);
process->kill();

To copy to clipboard, switch view to plain text mode 

should not list the name of the int parameter at line 2. Perhaps this leaves the finished() signal still connected?

Have you tried calling QProcess::terminate() (close gracefully) rather than QProcess::kill() (close with mallet)? I cannot imagine many Windows applications that ignore the WM_CLOSE message sent by terminate()

[norobro]

should not list the name of the int parameter at line 2. Perhaps this leaves the finished() signal still connected?

I missed that. I guess that is what borisbn is alluding to in post #4.
I put that slot in my app with the disconnect error and received a "no such slot" warning on the command line but the process still terminated without complaining.

[wally]

From post 7:

disconnect(process, SIGNAL(error(QProcess::ProcessError)), 0, 0);
disconnect(process, SIGNAL(finished(int exitCode, QProcess::ExitStatus)), 0,0);
process->kill();

disconnect(process, SIGNAL(error(QProcess::ProcessError)), 0, 0);
disconnect(process, SIGNAL(finished(int exitCode, QProcess::ExitStatus)), 0,0);
process->kill();

To copy to clipboard, switch view to plain text mode 

should not list the name of the int parameter at line 2. Perhaps this leaves the finished() signal still connected?

Have you tried calling QProcess::terminate() (close gracefully) rather than QProcess::kill() (close with mallet)? I cannot imagine many Windows applications that ignore the WM_CLOSE message sent by terminate()

Sorry that's a typo.. I don't have the name of the int parameter in my actual code.

Regarding QProcess::terminate() vs. QProcess::kill(), the documentation says that "Console applications on Windows that do not run an event loop, or whose event loop does not handle the WM_CLOSE message, can only be terminated by calling kill()." Since, I'm using this program to run any possible program (including console applications) I will have to stick with the "mallet."

[wally]

Hello Everyone,

Thank you for your help. The solution was my lack of awareness on what's happening when you call QProcess::kill(). I was trying to disconnect and then reconnect my signals by calling the connect immediately after calling kill() (like in post #6 where I call blockSignals before and after the kill call.

I got the idea from fatjuicymole when he made a comment about my post #6. The process object was getting its signals reconnected before the external program had been terminated, since QProcess::kill() is not a synchronous function as it does not wait for the external function to be terminated.

Now when I press the stop button, the slot stopProcess contains the following:

disconnect(process, SIGNAL(error(QProcess::ProcessError)), this, SLOT(handleProcessError(QProcess::ProcessError error)));
disconnect(process, SIGNAL(finished(int, QProcess::ExitStatus )), this, SLOT(handleProcessFinish(int, QProcess::ExitStatus)));
process->kill()

disconnect(process, SIGNAL(error(QProcess::ProcessError)), this, SLOT(handleProcessError(QProcess::ProcessError error)));
disconnect(process, SIGNAL(finished(int, QProcess::ExitStatus )), this, SLOT(handleProcessFinish(int, QProcess::ExitStatus)));
process->kill()

To copy to clipboard, switch view to plain text mode 

and then when I press the start button I reconnect the signals, e.g.:

connect(process, SIGNAL(error(QProcess::ProcessError)), this, SLOT(handleProcessError(QProcess::ProcessError error)));
connect(process, SIGNAL(finished(int, QProcess::ExitStatus )), this, SLOT(handleProcessFinish(int, QProcess::ExitStatus)));
process->start(processName);

connect(process, SIGNAL(error(QProcess::ProcessError)), this, SLOT(handleProcessError(QProcess::ProcessError error)));
connect(process, SIGNAL(finished(int, QProcess::ExitStatus )), this, SLOT(handleProcessFinish(int, QProcess::ExitStatus)));
process->start(processName);

To copy to clipboard, switch view to plain text mode 

Thanks for your help everyone. The problem, like usual, ended up being the user. You learn something new everyday, even though you realize that you should've known it anyways

[squidge]

Regarding QProcess::terminate() vs. QProcess::kill(), the documentation says that "Console applications on Windows that do not run an event loop, or whose event loop does not handle the WM_CLOSE message, can only be terminated by calling kill()." Since, I'm using this program to run any possible program (including console applications) I will have to stick with the "mallet."

A better idea might be to use QProcess::terminate(), and if the process doesn't terminate within some time frame, then use QProcess:kill(). At least then it'll give the process that amount of time to cleanup if necessary, and will also work in situations where the process doesn't handle WM_CLOSE.

[norobro]

@wally - I'm using Qt 4.6.0 on Linux.

I recently installed Qt 4.6.2 on my WinXP partiton and thought I'd give my simple app a try. I started "calc.exe" as a process and it ended silently. So disconnect worked here. Also it ended whether I used the "mallet" (TM ChrisW67) or terminate() .

[squidge]

Yup. See post #6

Didn't work either.

In post #6, you re-enable directly after the kill. I was thinking of leaving the blocking active until the process is restarted, just in case some signals are in the event queue.

[wally]

In post #6, you re-enable directly after the kill. I was thinking of leaving the blocking active until the process is restarted, just in case some signals are in the event queue.

Good point. I'll give that a shot.