Unsolved Qprocess show stdoutput only on ending of excecution.
-
@saran
Do two things:-
Replace
while(process->canReadLine())
and theprocess->readLine();
byQProcess::readAllStandardOutput()
. It avoids looping and relying on whenprocess->canReadLine()
returns true. (It also means we can try "unbufferred", whichcanReadLine()
says it cannot handle; you might want to retryQIODevice::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. -
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
howst-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.
-
-
@JNBarchan
When I said that I get "677", I was talking about theqWarning(QString::number(process->bytesAvailable()).toStdString().c_str());
line, this is consistent, when readOutput function is executed, all stdout bytes are availables for read, soprocess->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. -
@saran
OIC, that's because it has 677 bytes initially, then it manages to keep satisfying thecanReadLine
with more data which has arrived since, I guess. WE could have done with anotherqWarning(QString::number(process->bytesAvailable()).toStdString().c_str());
inside the loop.Never mind about that. Suggest you try my 2 recommendations and report back :)
-
@JNBarchan
-
The same with the replaces. The problem is in the SIGNAL, that is not generating the trigger on each new line.
-
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.
-
-
@saran
Yes, like it's being buffered there so you don't get it, that's the usual problem I suspected at start. Try theQIODevice::Unbuffered
now assuming you've changed to useQProcess::readAllStandardOutput()
instead ofprocess->readLine();
? -
@JNBarchan
There is noSIGNAL(readyReadStandardOutput()
norSIGNAL(readyRead()
when I putQIODevice::Unbuffered
. -
@saran
Hmm, that sounds odd to me, why would that be? -
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.....
-
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
-
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).