QThread with multiple methods

Christian Ehrlicher

You wanted to wait in the main dialog (for whatever reason) - I told you a solution.
Now you tell me you won't block the ui - so don't block it and connect a slot to the finished signal of the thread.

JohnCu

@Christian-Ehrlicher Ok, let me explain the situation one more time. I launch a function from a gui thread (gui class code). Then i need to wait for the function to finish its job, before i go to a subsequent line. However, mu gui thread event loop needs to be active all the time, in order to enable data plotting. I can not freeze gui thread, I need to have it responsible, but it needs to be waiting in a line of launching function from workers object. There should be something like "do subsequent line, but first perform action prompted by an indicated signal". For now it is handled in a loop mentioned before, but I know, that it is not an optimal solution...

Christian Ehrlicher

Again: connect a signal which is emitted from the thread when the first part is finished. Connect this signal to a slot in the gui thread which does the work you need to do in the gui thread which then emits another signal to do the next work in the thread.

JohnCu

@Christian-Ehrlicher Yes, I added such signal. But how should I check if the signal was emitted? I can not do a while loop, which constantly checks whether signal was emitted, because gui thread will be locked in such loop. Maybe you meant something else?

J.Hilk

@JohnCu you don't need to check that yourself

simply connect a slot to the signal, as soon as it is emitted and your main application is in no loop (infinite loop for example) the slot will be called!

JohnCu

@J-Hilk Yes, but my workers thread computation are a little bit time consuming, and I need to be sure, that before going to subsequent line in gui code (just after launching computation on workers thread) the computations are done. Your approach would work, if there is no more code in function, inside which workers thread method is launched.

J.Hilk

@JohnCu
I don't see the problem, YOU decide when the signal is emitted inside your code, don't you?

Emit the allDone signal when you're all done, and not before

JohnCu

@J-Hilk Yes, of course, there is no problem with emitting a signal from workers thread, I do it when computations are done. But, take look at this code from gui class:

emit onConnecttoHardware();

// if connected to hardware
QMessageBox::information(this, "Message", "Hardware connected");

First i launch action, then i show, that it is finished. however, after emitting a signal to start the action, the main thread goes straight to show QMessageBox, which can not be prompted before computations are done... I need to wait at the first line of this code to obtain allDone signal and have my gui responsible while waiting, because i need to plot some results, which are also prompted by a signal emitted from workers thread. If I do as you suggested, main thread displays messagebox immediately, before action finished (allDone signal is emitted)...

aha_1980

@JohnCu said in QThread with multiple methods:

I need to wait at the first line of this code to obtain allDone signal and have my gui responsible while waiting,

And this, you have to understand, is a discrepance.

You cannot wait in GUI threads.

What you probably want to do is, to disallow user input until the allDone signal is received. And that's how it's usually done in professional apps.

You most likely also want your user to be able to abort the process, in case something goes wrong. All that is impossible if the GUI thread stucks.

Regards

J.Hilk

@JohnCu

add the following signals to your worker

signals:
	void on_enable_buttons();
	void update_plot();
//new
       void onHardwareConnected();
       void onOperationSuccesfull

Connects in your App.cpp

connect(&worker, &Worker:: onHardwareConnected, this, App:: onRun);
connect(&worker, &Worker:: onHardwareConnected, this, [=]()->void{QMessageBox::information(this, "Message", "Hardware connected");});
connect(&worker, &Worker:: onOperationSuccesfull, this, [=]()->void{
     QMessageBox::information(this, "Message", "Operation succesful");
     enable_all_buttons();
});

void App::on_Run_triggered()
{
	disable_all_buttons();
        emit onConnecttoHardware();
	QMessageBox::information(this, "Message", "Prepare hardware");
}

something like this could work

JohnCu

@aha_1980 said in QThread with multiple methods:

@JohnCu said in QThread with multiple methods:

I need to wait at the first line of this code to obtain allDone signal and have my gui responsible while waiting,

And this, you have to understand, is a discrepance.

You cannot wait in GUI threads.

What you probably want to do is, to disallow user input until the allDone signal is received. And that's how it's usually done in professional apps.

You most likely also want your user to be able to abort the process, in case something goes wrong. All that is impossible if the GUI thread stucks.

Regards

Yes, that is exactly what I want. I know, that I cannot block a GUI thread. So how would you solve this problem? I just want this thread to respond for incoming signals, which will finally allow to step it to subsequent line. I want to tell compiler "stay here, process incoming signals and continue to subsequent line (within this method), as soon as indicated signal will be emitted"

@aha_1980 said in QThread with multiple methods:

@JohnCu said in QThread with multiple methods:

I need to wait at the first line of this code to obtain allDone signal and have my gui responsible while waiting,

And this, you have to understand, is a discrepance.

You cannot wait in GUI threads.

What you probably want to do is, to disallow user input until the allDone signal is received. And that's how it's usually done in professional apps.

You most likely also want your user to be able to abort the process, in case something goes wrong. All that is impossible if the GUI thread stucks.

Regards

Thanks, it would work if there is only one function called from on_Run_triggered() method, but there are more:

void App::on_Run_triggered()

{
disable_all_buttons();
QMessageBox::information(this, "Message", "Prepare hardware");

emit onConnecttoHardware();

// if connected to hardware
QMessageBox::information(this, "Message", "Hardware connected");

emit onRun();
		
QMessageBox::information(this, "Message", "Operation succesful");

}

The problem is, that I cannot emit onRun() before I am not sure if hardware was connected properly... Based on your responses, the only way to make it work (besides QEventLoop, that I mentioned before, however it is not safe) would be to split on_Run_triggered() method and place rest of the code into another method, which would be called via slot after getting allDone signal? So after calling first method, a main gui thread will exit on_Run_triggered() and will be waiting for subsequent signal emissions i.e. allDone. am I right?

I think, a similar problem was described here: https://stackoverflow.com/questions/3556421/blocked-waiting-for-a-asynchronous-qt-signal

J.Hilk

@JohnCu said in QThread with multiple methods:

would be to split on_Run_triggered() method and place rest of the code into another method, which would be called via slot after getting allDone signal? So after calling first method, a main gui thread will exit on_Run_triggered() and will be waiting for subsequent signal emissions i.e. allDone. am I right?

In essence, yes!

JohnCu

@J-Hilk I wanted to avoid such approach, because it will totally ruin my code structure, but if it is necessary...

aha_1980

@JohnCu

I'm about giving up with you!

I want to tell compiler "stay here, process incoming signals and continue to subsequent line (within this method), as soon as indicated signal will be emitted"

And that is exactly what is not possible. Forget it.

I think, a similar problem was described here: https://stackoverflow.com/questions/3556421/blocked-waiting-for-a-asynchronous-qt-signal

Don't do that. You will regret it.

As said multiple times: don't block the GUI thread. Let it run free.

Regards

JohnCu

@aha_1980 I am sorry for testing your patience ! I will locate the code in a separate methods, in order not to block gui thread. However, thank you for your advice!

aha_1980

@JohnCu No problem.

I know making your head up with async programming is hard in the beginning.

But it will get better :)

JKSH

@JohnCu said in QThread with multiple methods:

@J-Hilk I wanted to avoid such approach, because it will totally ruin my code structure, but if it is necessary...

It is very necessary. Do not try to take the easy way out.

Think of it this way: You are not ruining your code structure, you are improving it to become a responsive, event-driven structure.

To do asynchronous/event-driven programming (responding to signals/events from other threads), you must think differently and structure your code differently.