Including files

programthis

@programthis said in Including files:

But class B still lacks it's definition so I can't reference an object of that class and connect to the slot.

How does class B look like? Does it have a slot called on_ON_clicked?

Where do you create the instance of B? In A's c'tor?

First of all thanks for the reply!

Class B indeed has a private slot called on_ON_clicked
The instance of B is created in the private section of the "A.h"
By 'created' I mean declared.

I've created this snippet, maybe it will be easier to see:
https://gitlab.com/-/snippets/2106333

SGaist

Hi and welcome to devnet,

How do you know that the processing is done ?

From a quick look at your code, you might not even need that signal to enable your other widget again.

programthis

@SGaist said in Including files:

Hi and welcome to devnet,

How do you know that the processing is done ?

From a quick look at your code, you might not even need that signal to enable your other widget again.

I used the std::this_thread::sleep_for(std::chrono::seconds(40)); function for the time it takes the processing to complete.
The widget opens via script command but it's on 'OFF' mode and I want to turn it 'ON' so that's why I want to signal.

SGaist

Using sleep is a bad idea because you are going to block the event loop.

So how is the processing started ?

programthis

@SGaist said in Including files:

Using sleep is a bad idea because you are going to block the event loop.

I am using it precisely to block the event loop so I can call script commands that run different programs in order without overlapping each other.

So how is the processing started ?

Also a program that gets called through a script command. Once it finishes, it in itself calls SYSTEM_START again through a script command but like I said, SYSTEM_START is called in 'OFF' mode and I want it to launch and then to turn it back on so the system resumes normal function.

SGaist

Then you have an architecture issue.

If you have several scripts to call then make a list of them and use QProcess to call them one after the other leveraging its asynchronous nature.

You will then be able to better manage your widgets.

programthis

@SGaist said in Including files:

Then you have an architecture issue.

If you have several scripts to call then make a list of them and use QProcess to call them one after the other leveraging its asynchronous nature.

You will then be able to better manage your widgets.

Alright, looking into it now.
Just for reference, this is the .cpp file:
https://gitlab.com/-/snippets/2106380

SGaist

I confirm my original diagnostic.

No need for that intermediate signal and you definitely want to use QProcess.

programthis

@SGaist said in Including files:

I confirm my original diagnostic.

No need for that intermediate signal and you definitely want to use QProcess.

Alright, I'm looking in to QProccess and re writing the code

programthis

@SGaist
How do you actually let QProcess know when to wait not only for the script to run, but for the program that the script calls as well?

QProcess *q1 = new QProcess(this);
    q1->execute("/bin/sh", QStringList() << "/full/path/Run_GUI_Kill.sh &");
    q1->waitForFinished();
    q1->execute("/bin/sh", QStringList() << "/full/path/SYSTEM_START_Kill.sh &");
    q1->waitForFinished();
    q1->execute("/bin/sh", QStringList() << "/full/path/PROCESS_ALGORITHM.sh &");
    q1->waitForFinished();
    q1->execute("/bin/sh", QStringList() << "/full/path/Run_GUI.sh &");
    q1->waitForFinished();

If I run this, it will call all the programs without actually waiting for everything to finish up before starting the next one in order, including the process algorithm that needs time to run.

SGaist

First, remove that & from your script calls.

Next, use QProcess::finished to get the information that your script is done. You should also check the error just in case something goes wrong.

As already suggested, use a list of all your commands and pick the next one each time the previous script ended successfully.

programthis

@SGaist said in Including files:

First, remove that & from your script calls.

Next, use QProcess::finished to get the information that your script is done. You should also check the error just in case something goes wrong.

As already suggested, use a list of all your commands and pick the next one each time the previous script ended successfully.

But that is it, the script finishes in less than a second. It launches a compiled program or process which I don't know when it ends(or starts, for that matter). That's why I used the sleep function in the first place.

How would you use the QProcess::finished function to determine that a system process has finished?

Here is my take on it: https://gitlab.com/-/snippets/2106599

Note that this isn't even why I started the thread. I had a problem with calling a class instance from a different project.
The sleep function was working perfectly fine.. I don't know why I even need this QProccess stuff...

SGaist

Because using sleep to ensure your process is done is not the right way to ensure it has run and that it happened without error.