Qprocess show stdoutput only on ending of excecution.

[saran]

@jsulm
process->start is the last line.
I have

process->setReadChannel(QProcess::StandardOutput);
process->setProcessChannelMode(QProcess::MergedChannels);
process->setCurrentReadChannel(QProcess::StandardOutput);

Just to make sure the process writes to stdout but anyway, without those lines the behavior is the same.

On readOutput I have:

void softsWindow::readOutput(){
    qWarning(QString::number(process->bytesAvailable()).toStdString().c_str());
    while(process->canReadLine()){
        QByteArray linea = process->readLine();
        ui->textBrowser->append(linea);        
    }
} 

As you can see, the function directs the text of the stdout to a QTextBrowser
With the qWarning(QString::number(process->bytesAvailable()).toStdString().c_str()); line, I can see that the function receives all the data at once. the line print a "677" on application output, at same time the QTextBrowser print all the output.

[JonB]

@saran
Do two things:

1. Replace while(process->canReadLine()) and the process->readLine(); by QProcess::readAllStandardOutput(). It avoids looping and relying on when process->canReadLine() returns true. (It also means we can try "unbufferred", which canReadLine() says it cannot handle; you might want to retry QIODevice::Unbuffered to see if that now makes any difference.) I would think about doing it like that anyway, unless you have reason to want to only grab whole lines at a time for output.

2. Replace the command you're executing by one which produces voluminous output, e.g. dir /s c:\. What arrives when? Does the subprocess actually get stuck because the parent has failed to read its output as it goes along, which is what will happen if the signal only ever arrives at the end? We need to know whether behaviour is linked to
   how st-link_cli.exe produces its output versus anything else.

BTW, if when you last ran it returned just "677" as you say, that does not correspond at all to the output you show in your screenshot. Please try to keep things consistent since we are measuring when output arrives.

[saran]

@JNBarchan
When I said that I get "677", I was talking about the qWarning(QString::number(process->bytesAvailable()).toStdString().c_str()); line, this is consistent, when readOutput function is executed, all stdout bytes are availables for read, so process->bytesAvailable() is 677, that is the characters count.
The screenshot shows the output when I run st-link_cli.exe on cmd.exe, as astated above.

[JonB]

@saran
OIC, that's because it has 677 bytes initially, then it manages to keep satisfying the canReadLine with more data which has arrived since, I guess. WE could have done with another qWarning(QString::number(process->bytesAvailable()).toStdString().c_str()); inside the loop.

Never mind about that. Suggest you try my 2 recommendations and report back :)

[saran]

@JNBarchan

1. The same with the replaces. The problem is in the SIGNAL, that is not generating the trigger on each new line.

2. I tried the following and the code works as I expected:

    QString file = "ping";
    QStringList argumentos << "192.168.0.1";
    process->start(file,argumentos);

Result: 5 SIGNAL(readyReadStandardOutput()), on each one, the readOutoput function printed correctly the output on the QTextBrowser.

So the problem is the st-link_cli.exe output.

[JonB]

@saran
Yes, like it's being buffered there so you don't get it, that's the usual problem I suspected at start. Try the QIODevice::Unbuffered now assuming you've changed to use QProcess::readAllStandardOutput() instead of process->readLine(); ?

[saran]

@JNBarchan
There is no SIGNAL(readyReadStandardOutput() nor SIGNAL(readyRead() when I put QIODevice::Unbuffered .

[JonB]

@saran
Hmm, that sounds odd to me, why would that be?

[jdascenzio]

I have the same trouble. It's seems to happen when the end of line send by a process is only \n instead of \r\n for windows.....

[greenpitaya]

Also facing the same issues, ping works fine realtime, but the readyRead signal isnt getting triggered when theres a 'print' command on my custom executable. As everyone else, it gets triggered only after the process is completed.

@saran were you able to debug this problem eventually?

@jdascenzio does using \r \n solve this problem? It did not for me

[jarl93rsa]

Yes I realise this topic is old, but replying to it anyway as it's one of the first things that appear in google when you search this issue.

For anyone who hasn't resolved this there's a chance your application is buffering its stdout, and it's not a problem on the qt side.

I had this same issue, my logging functions writing to stdout in the application I was trying to get output from wouldn't show until the process had finished. It was resolved by flushing stdout.

In my case my c program log function would write to printf(), and at the end of those functions I needed to put fflush(stdout).