QProcess does not do what I expected...

Anonymous_Banned275

This post is deleted!

JonB

@AnneRanch said in QProcess does not do what I expected...:

I get QProcess "finished" signal in abut 10 ms which is NOT "scan" finished SIGNAL.

I cannot comment on this. On my system the hcitool dev command you previously showed returns immediately, with no devices found. The waitForFinished()/finished signal will arrive as and when the command you specify finished, full-stop/period/end-of-story. It will be the same as if you use system() or type the command into a shell terminal.

If I implement "waitforfinshed" the code does exactly that and block everything until timeout expires.

I could do that with "system" and that is why I went with QProcess .

How do I modify QProcess so it

does not block process - remove "waitforfinished" ??

Indeed, waitForFinished() makes it behave like system(). In order not to block, do not use that, instead you must use the void QProcess::finished(int exitCode, QProcess::ExitStatus exitStatus) signal to tell a slot of yours when it is finished. Don't forget to connect other signals (e.g. errorOccurred()), and don't forget your QProcess instance must not go out of scope while the command is running.

KroMignon

@AnneRanch said in QProcess does not do what I expected...:

How do I modify QProcess so it

does not block process - remove "waitforfinished" ??

sets "finshed" when the "scan" is actually done
(I could just read the state and what was written to file - or read the standard stdio to make sure the process output is as expected )

Can I restart the same process to finish the 'scan" ??
( i could look for EOF .....)

QString text = Command + " >> /tmp/temp";
 OProcess.start("/bin/sh", QStringList() << "-c" << text );
qDebug() << " Process before waiting " << OProcess.state();
//OProcess.waitForFinished(); // 60000);
qDebug() << " Process AFTER  waiting " << OProcess.state();
qDebug() << OProcess.state();
qDebug() << "Process finished ";
qDebug(" END int  Form::RunProcess_Asynch(QString Commnd)");

Please understand difference between asynchronous and synchronous usage of QProcess.
You should never mix-up synchronous and asynchronous functions with a QProcess instance.

With asynchronous, I mean signals/slots mechanism and with QProcess::waitForXXXX() functions.
When calling QProcess::start() nothing directly happen, all events are registered in event queue (for example state() is not updated).
To made things work, you to loop in the event queue.
The alternative is to use QProcerss::waitForXXX() functions which enable the call of the event loop and wait until the specified event happens.

I don't understand why you want to use QProcess and not continue with system() calls.
I would only made sense to me, if you want to directly capture called process output and handle it in your application without having to redirect to a file a read from file.

JonB

@KroMignon said in QProcess does not do what I expected...:

I don't understand why you want to use QProcess and not continue with system() calls.

I believe the OP has previously said: she does not want to block while waiting for system() or QProcess::waitForFinished() to complete.

KroMignon

@JonB said in QProcess does not do what I expected...:

I believe the OP has previously said: she does not want to block while waiting for system() or QProcess::waitForFinished() to complete.

There are other alternative to do that, so example using QtConcurrent::run() ==> https://doc.qt.io/qt-5/qtconcurrentrun.html

JonB

@KroMignon
I cannot imagine why one would choose to use QtConcurrent::run() plus system()/waitForFinished() blocking calls when you have a perfectly good asynchronous QProcess::start() plus finished signal, which I and others have used many times.

Christian Ehrlicher

@KroMignon I don't see any resaon to use a thread here. But since you both are masochist and trying to explain the QProcess usage since more than one year without any real success - do whatever you like :D

KroMignon

@JonB said in QProcess does not do what I expected...:

I cannot imagine why one would choose to use QtConcurrent::run() plus system()/waitForFinished() blocking calls when you have a perfectly good asynchronous QProcess::start() plus finished signal, which I and others have used many times.

Okay, we are talking about 2 different things.
My suggestion was to continue with working system() calls but using QtConcurrent:run() to not do it in main thread.
e.g.:

QtConcurrent::run([text](){ 
    qDebug() << "starting system call:" << text;
    system(text.toLatin1().begin());
    qDebug() << "System call done";
 });

I guess this is the only thing @AnneRanch wants to achieve.
To be clear, it is not the way I would do it... But, according to all exchanges with @AnneRanch, it looks to me to be the best alternative to QProcess, as he (or she) seems not be ready to understand/accept difference between asynchronous and synchronous usage of QProcess.

JonB

@KroMignon
I understand your position. Personally I try to keep people away from threads as long as possible, as I see too many things going wrong when they do use them. Before we know it, we will have to discuss what can and cannot be done in that thread run, such as (not) updating the UI.... The trade-off is that if the OP does not learn about asynchronous QProcess they will have to learn about asynchronous QtConcurrent:run() instead :)

KroMignon

@JonB said in QProcess does not do what I expected...:

The trade-off is that if the OP does not learn about asynchronous QProcess they will have to learn about asynchronous QtConcurrent:run() instead :)

Yes your are right, but you cannot teach anyone, if he don't accept to listen to you.
Sometimes, person are not ready to accept arguments.
So you can continue to write always to same thing with different words (as I am not an english native speaker, it becomes quickly hard to me), or propose alternatives...

I try it with alternatives, but I not sure it will be accepted anyway :D