I'm a newbie in using QT
Code :
void MainWindow::test()
{
ui->label->setText("it worked !");
proc->start("c:/windows/system32/calc.exe");
}
void MainWindow::on_pushButton_clicked()
{
proc = new QProcess();
connect(proc,SIGNAL(finished(int,QProcess::ExitStatus)),this,SLOT(test()));
proc->start("c:/windows/system32/notepad.exe");
}
So it starts notepad when I close it, calc is started but it keeps opening infinitely.
What's wrong in my code?
Since you are not disconnecting the slot, the moment "calc.exe" exits it will be launched again.
I.e. when notepad.exe finishes, the signal triggers the test() slot which runs "calc.exe".
When "calc.exec" finished, the very same series of events happens again.
Related
I am trying to run a script in parallel to my Qt program and am having trouble starting it as a separate process. Check out my attempts below and let me know what you see wrong.
The first attempt was just a system call:
system("python3 startprocess.py");
This works but it also stops the program while running it.
I then followed this guy https://forum.qt.io/topic/92205/writing-commands-to-linux-bash with no success. No errors, just no start of my script.
I am trying this after I saw the documentation and have the below code.
QProcess process;
process.start("python3 startprocess.py");
process.waitForStarted();
I am just wanting to start this script and have it run at the same time as my C++ code. Perhaps I am using the QProcess wrong?
UPDATE:
It was a lot easier to use QThreading and the original system call.
I think the issue is that the QProcess doesn't have the file path and fails to find and start it! I suggest first to use the full file path! Also check the QProcess::setWorkingDirectory and QProcess::setProcessEnvironment that are useful to handle this case!
Update
In order to prevent the QProcess to be killed while running and without freezing the GUI, you need to define it as a pointer, then connect the QProcess::finished event; in the slot, you can check the exit code and delete the sender using QObject::deleteLater method. Check both the Qt example and the QProcess::finished.
Update 2
Try this code:
auto process = new QProcess(this);
connect(process, QOverload<int,QProcess::ExitStatus>::of(&QProcess::finished),
[this](int exitCode, QProcess::ExitStatus exitStatus)
{
if (exitStatus == QProcess::ExitStatus::CrashExit
|| exitCode != 0) {
// Process error!
} else {
// Process OK!
}
});
process->setWorkingDirectory("startprocess.py folder location");
process->start("python3 startprocess.py");
if (!process->waitForStarted(-1)) {
// Failed to start process
delete process;
}
I'm trying to use QProcess inside a thread to do some operations (read I2C connections).The update method is calling every 100 msec:
void TempsReader::update()
{
if (_currProcess == nullptr) {
_currProcess = new QProcess();
connect(_currProcess, &QProcess::errorOccurred, this, &TempsReader::onProcessError);
connect(_currProcess, SIGNAL(finished(int,QProcess::ExitStatus)),
this, SLOT(onProcessFinished()));
}
_currProcess->start("sh");
if (_currProcess->waitForStarted()) {
_currProcess->write("i2cdetect -y 1");
_currProcess->closeWriteChannel();
_currProcess->waitForFinished();
}
}
After some time, the process gives "FailedToStart" error and never starts again.
void TempsReader::onProcessError(QProcess::ProcessError error)
{
qDebug() << error;
_currProcess->close();
}
void TempsReader::onProcessFinished()
{
QString devs = _currProcess->readAll();
_currProcess->waitForFinished();
// doing some stuff with devs
_currProcess->close();
}
How can I fix this issue? Am I using QProcess in a wrong way? and how can I start the process again when it drops in error slot. Thanks in advance.
Update: QProcess::errorString() gives this: "Resource error (fork failure): Too many open files"
UPDATE: Finally I've found the issue and it was not related to QProcess itself. It was relating to I2C connection.
My guess is that you get the failure because all your update() calls share the same QProcess object.
What happens here is that when you call update(), you start the process. And 100ms later, you call it again without ensuring that the previous update() has finished to wait the end of the process.
The consequence is that you try to start an already started process and thus it fails.
For me, the easiest solution is to create one QProcess object for each update() call.
Something like:
void TempsReader::update()
{
QProcess * current_process = new QProcess;
connect(current_process, &QProcess::errorOccured, this, &TempReader::onProcessError);
connect(current_process, QOverload<int, QProcess::ExitStatus>::of(&QProcess::finished), this, &TempReader::onProcessFinished());
current_process->start("sh"); // Your command
current_process->waitForStarted();
current_process->write("i2cdetect -y 1");
current_process->waitForFinished();
current_process->deleteLater();
}
Or without pointers:
void TempsReader::update()
{
QProcess current_process;
connect(¤t_process, &QProcess::errorOccured, this, &TempReader::onProcessError);
connect(¤t_process, QOverload<int, QProcess::ExitStatus>::of(&QProcess::finished), this, &TempReader::onProcessFinished());
current_process.start("sh"); // Your command
current_process.waitForStarted();
current_process.write("i2cdetect -y 1");
current_process.waitForFinished();
}
As you did not show the calling part of the code (the thread creation, the 100ms loop, ...), this may not be the solution you need.
In this case, please let me know if it does not solve your issue so that I'll remove this answer.
Finally I've found the issue and it was not related to QProcess itself. It was relating to I2C connection. I was using this command in update: wiringPiI2CSetup(addr); and it opens a new device each time.
I am running a Qt app that launches a process. (The Assistant, launched from the main app).
When I close the app, I get the warning
QProcess: Destroyed while process is still running.
How can I get rid of it ?
I saw this similar question and tried to kill... Nothing happened.
This question seems to say maybe I should add waitForFinished()... Help won't close when app does.
Help::Help():m_helpProcess(0) {}
Help::~Help()
{
if (m_helpProcess) {
m_helpProcess.waitForFinished(); // help stays open after app closes
m_helpProcess->kill(); // added with no effect
delete m_helpProcess;
}
}
bool Help::start()
{
if (!m_helpProcess)
process = new QProcess();
QStringList args;
args << QLatin1String("-collectionFile")
<< QLatin1String("mycollection.qhc");
process->start(QLatin1String("Assistant.app"), args);
if (!process->waitForStarted())
return;
}
It should be sufficient to rewrite the destructor using close():
Closes all communication with the process and kills it. After calling this function, QProcess will no longer emit readyRead(), and data can no longer be read or written.
Help::~Help()
{
if (m_helpProcess) {
// m_helpProcess->waitForFinished(); // help stays open after app closes
m_helpProcess->close(); // close channels
delete m_helpProcess; // destructor actually kills the process
}
}
I want to monitor an Emergency Stop button in custom equipment attached to a Beaglebone, my code is developed with Qt 4.6.
At the moment, I successfully 'show' a message box (without any buttons) when the Emergency Stop button is pressed. What I want to do is to proceed with the program ONLY when the Emergency Stop button is released. The Button press/release emit separate signals on each event. However, using this code the EmergencyStopIsInactive signal is never detected.
QEventLoop loop;
connect(this, SIGNAL(EmergencyStopIsInactive()), &loop, SLOT(quit()));
loop.exec(QEventLoop::AllEvents);
qDebug() << "Emergency Stop Deactivated";
In fact, using breakpoints I can see that it is never generated. The Eventloop seems to not receive the signal.
If I comment out the loop.exec line, using breakpoints I can see that the code emits the signal. With the exec command back in, we never reach the breakpoints.
The exec() does not seem to be allowing the application to process events.
Can I get this to work the way I want? How?
Regards,
James
=======================================
Edit:
This is the code that generates the initial signal:
// Set up Emergency Stop Input
EmStop = new mita_gpio;
EmStop->initgpio_read(49);
connect(EmStop,SIGNAL(StateOutput(unsigned int)), this, SLOT(update_EmStop(unsigned int) ) );
connect(EmStop,SIGNAL(StateOutput(unsigned int)), Test_Screen, SLOT(update_EmStop(unsigned int) ) );
connect(this,SIGNAL(EmergencyStopIsInactive()), Probe_Screen, SLOT(quit() ) );
connect(Probe_Screen,SIGNAL(ShowEmergencyStopScreen()),this,SLOT(EmergencyStopScreenShow()) );
This signal is then chained to the following:
void Manager::update_EmStop(unsigned int state_value)
{
if (state_value == 1)
{
MitaData.EmergencyStop = 1;
emit EmergencyStopIsActive();
qDebug() << "Emergency Stop = 1";
}
else
{
MitaData.EmergencyStop = 0;
emit EmergencyStopIsInactive();
qDebug() << "Emergency Stop = 0";
}
}
SIGNAL(EmergencyStopIsInactive()) is executing in the main event loop of your program (I logically assume).
When you start a new event loop, you run it with the blocking function exec and thus despite your new loop is running, you are blocking the main event loop.
loop.exec(QEventLoop::AllEvents);
Since your signal is supposed to be sent from the main loop, that is blocked by your blocking function loop.exec, it will never be sent until the loop.exec is returning.
To solve that issue, whether generate the EmergencyStopIsInactive() signal from within the "loop" event loop, or put this second loop inside a separate thread.
I've a dialog displaying progress bar + some other data, and I also have a cancel button on this dialog. While this dialog is displayed there is potentially heavy computation going on, which is show on progress bar. This computation is started from withing this dialog code so I have:
Counting_Progress_Dialog::Counting_Progress_Dialog(QWidget *parent) :
QDialog(parent)
{
setupUi(this);
thread_ = new Threaded;//THIS IS THE THREAD IN WHICH COMPUTATION IS BEING PERFORMED
connect(thread_,SIGNAL(counter_value(int)),this,SLOT(update_progress_bar(int)));
connect(this,SIGNAL(rejected()),thread_,SLOT(terminate()),Qt::QueuedConnection);//
HERE I'M CONNECTING REJECTED ON DIALOG TO TERMINATE ON THREAD
}
void Counting_Progress_Dialog::start()
{
thread_->start(QThread::LowestPriority);
}
and I do invoke this in part of the program:
void My_Class::dummy_()
{
auto old_priority = this->thread()->priority();
this->thread()->setPriority(QThread::HighestPriority);
Counting_Progress_Dialog progress;
progress.start();//this will start thread
progress.exec();//this will enter it's event loop
progress.wait();//this will wait until thread is finished
this->thread()->setPriority(QThread::NormalPriority);
}
But despite all this, when I press cancel on my dialog, the whole application freezes. What am I doing wrong? How to make it behave correctly?
UPDATED:
void Counting_Progress_Dialog::wait()
{
thread_->wait();
}
I see that you are connecting using 2 different strategies. But if thread_ and this(counting dialog) are really within two separated threads then the connection will always be Qt::QueuedConnection. Well that's not the issue.
progress.exec();//this will enter it's event loop
Calling exec() suspend the execution of dummy_() until the dialog have to return. And when the dialog return your thread is terminated. So I don't see the purpose of
progress.wait();//this will wait until thread is finished
By the way which function is that? the only one I know is Qthread::wait(). I am pretty confident the issue is here...
edit:
progress.wait() is not the issue... But it is possible that the events sent by the thread are causing trouble in some way. Use the debugger or some qDebug() to see if update_progress_bar is called after you push cancel.