Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QThread with multiple methods
QtWS25 Last Chance

QThread with multiple methods

Scheduled Pinned Locked Moved Unsolved General and Desktop
33 Posts 5 Posters 3.5k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Christian EhrlicherC 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.

    J Offline
    J Offline
    JohnCu
    wrote on last edited by
    #20

    @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.HilkJ 1 Reply Last reply
    0
    • J 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.HilkJ Offline
      J.HilkJ Offline
      J.Hilk
      Moderators
      wrote on last edited by
      #21

      @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!


      Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


      Q: What's that?
      A: It's blue light.
      Q: What does it do?
      A: It turns blue.

      J 1 Reply Last reply
      1
      • J.HilkJ 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!

        J Offline
        J Offline
        JohnCu
        wrote on last edited by
        #22

        @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.HilkJ 1 Reply Last reply
        0
        • J 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.HilkJ Offline
          J.HilkJ Offline
          J.Hilk
          Moderators
          wrote on last edited by
          #23

          @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


          Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


          Q: What's that?
          A: It's blue light.
          Q: What does it do?
          A: It turns blue.

          J 1 Reply Last reply
          1
          • J.HilkJ 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

            J Offline
            J Offline
            JohnCu
            wrote on last edited by
            #24

            @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_1980A 1 Reply Last reply
            0
            • J 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_1980A Offline
              aha_1980A Offline
              aha_1980
              Lifetime Qt Champion
              wrote on last edited by
              #25

              @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

              Qt has to stay free or it will die.

              1 Reply Last reply
              2
              • J.HilkJ Offline
                J.HilkJ Offline
                J.Hilk
                Moderators
                wrote on last edited by
                #26

                @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


                Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                Q: What's that?
                A: It's blue light.
                Q: What does it do?
                A: It turns blue.

                1 Reply Last reply
                2
                • J Offline
                  J Offline
                  JohnCu
                  wrote on last edited by JohnCu
                  #27

                  @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.HilkJ 1 Reply Last reply
                  0
                  • J 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.HilkJ Offline
                    J.HilkJ Offline
                    J.Hilk
                    Moderators
                    wrote on last edited by
                    #28

                    @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!


                    Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                    Q: What's that?
                    A: It's blue light.
                    Q: What does it do?
                    A: It turns blue.

                    J 1 Reply Last reply
                    0
                    • J.HilkJ 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!

                      J Offline
                      J Offline
                      JohnCu
                      wrote on last edited by
                      #29

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

                      aha_1980A JKSHJ 2 Replies Last reply
                      0
                      • J JohnCu

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

                        aha_1980A Offline
                        aha_1980A Offline
                        aha_1980
                        Lifetime Qt Champion
                        wrote on last edited by
                        #30

                        @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

                        Qt has to stay free or it will die.

                        J 1 Reply Last reply
                        0
                        • aha_1980A 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

                          J Offline
                          J Offline
                          JohnCu
                          wrote on last edited by
                          #31

                          @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_1980A 1 Reply Last reply
                          3
                          • J 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_1980A Offline
                            aha_1980A Offline
                            aha_1980
                            Lifetime Qt Champion
                            wrote on last edited by
                            #32

                            @JohnCu No problem.

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

                            But it will get better :)

                            Qt has to stay free or it will die.

                            1 Reply Last reply
                            1
                            • J JohnCu

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

                              JKSHJ Offline
                              JKSHJ Offline
                              JKSH
                              Moderators
                              wrote on last edited by JKSH
                              #33

                              @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.

                              Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                              1 Reply Last reply
                              2

                              • Login

                              • Login or register to search.
                              • First post
                                Last post
                              0
                              • Categories
                              • Recent
                              • Tags
                              • Popular
                              • Users
                              • Groups
                              • Search
                              • Get Qt Extensions
                              • Unsolved