Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Mobile and Embedded
  4. Threading Acts Differently on the Debugger
Forum Update on Monday, May 27th 2025

Threading Acts Differently on the Debugger

Scheduled Pinned Locked Moved Unsolved Mobile and Embedded
3 Posts 2 Posters 493 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.
  • mstothM Offline
    mstothM Offline
    mstoth
    wrote on last edited by mstoth
    #1

    I'm new to threading and perhaps I didn't do it correctly but I'm seeing one kind of behavior on my desktop, and another kind of behavior on the embedded device (BeagleBone Black).

    My application has a singleton object called a Messenger, which communicates to a server through a tcp/ip pipe. I wanted to run this messenger in a separate thread so I did the following:
    (I typedef the Messenger singleton to Communicator and invoke it with an Instance method)

    typedef Singleton<Messenger> Communicator;
    
    

    In the interface,

    class MainWindow : public QMainWindow
    {
        Q_OBJECT
        QThread messengerThread;
    
    ... more code
    

    and then in the constructor,

        Communicator::Instance()->moveToThread(&messengerThread);
        messengerThread.start();
    

    In the main window, I present a progress bar for feedback while the app sets up the main window buttons, labels, etc. I want that progress bar to be shown while the Messenger sends and receives messages from the server.

        dss = new DialogStartupScreen(this);
        dss->setGeometry(QRect(QPoint(0,0),QPoint(480,272)));
    
        dss->show();
        dss->setProgressBar(0);
        dss->incrementProgressBar("Please wait, connecting...");
        qApp->processEvents();
    

    The call to processEvents() is meant to make sure the progress bar is displayed.
    This works fine on the debugger running on my desktop, however when I run on the embedded device, I still see all the items getting populated, watching the names getting assigned to buttons, etc. and I don't see the progress bar screen.

    On the debugger as soon as I execute processEvents, I see the proper startup screen.
    While I'm running on the debugger, I have the connection to the same server. The only difference is that I'm running on the desktop instead of the embedded device.

    There is something I don't understand about why it behaves differently on the BeagleBone.

    Any thoughts that might point me in the right direction? Many Thanks!

    jsulmJ 1 Reply Last reply
    0
    • mstothM mstoth

      I'm new to threading and perhaps I didn't do it correctly but I'm seeing one kind of behavior on my desktop, and another kind of behavior on the embedded device (BeagleBone Black).

      My application has a singleton object called a Messenger, which communicates to a server through a tcp/ip pipe. I wanted to run this messenger in a separate thread so I did the following:
      (I typedef the Messenger singleton to Communicator and invoke it with an Instance method)

      typedef Singleton<Messenger> Communicator;
      
      

      In the interface,

      class MainWindow : public QMainWindow
      {
          Q_OBJECT
          QThread messengerThread;
      
      ... more code
      

      and then in the constructor,

          Communicator::Instance()->moveToThread(&messengerThread);
          messengerThread.start();
      

      In the main window, I present a progress bar for feedback while the app sets up the main window buttons, labels, etc. I want that progress bar to be shown while the Messenger sends and receives messages from the server.

          dss = new DialogStartupScreen(this);
          dss->setGeometry(QRect(QPoint(0,0),QPoint(480,272)));
      
          dss->show();
          dss->setProgressBar(0);
          dss->incrementProgressBar("Please wait, connecting...");
          qApp->processEvents();
      

      The call to processEvents() is meant to make sure the progress bar is displayed.
      This works fine on the debugger running on my desktop, however when I run on the embedded device, I still see all the items getting populated, watching the names getting assigned to buttons, etc. and I don't see the progress bar screen.

      On the debugger as soon as I execute processEvents, I see the proper startup screen.
      While I'm running on the debugger, I have the connection to the same server. The only difference is that I'm running on the desktop instead of the embedded device.

      There is something I don't understand about why it behaves differently on the BeagleBone.

      Any thoughts that might point me in the right direction? Many Thanks!

      jsulmJ Offline
      jsulmJ Offline
      jsulm
      Lifetime Qt Champion
      wrote on last edited by
      #2

      @mstoth said in Threading Acts Differently on the Debugger:

      dss = new DialogStartupScreen(this);

      I guess you do this after ui->setupUI(this)?
      Create and show this dialog as an independent window before calling ui->setupUI(this).

      https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      0
      • mstothM Offline
        mstothM Offline
        mstoth
        wrote on last edited by
        #3

        Thanks! That caused the screen to display, but then it goes away again and I get to see my buttons and labels constructed even though it initially shows up. I must be doing something that puts the main window on top again. I will continue to investigate but it looks like you got me headed on the right track!

        1 Reply Last reply
        0

        • Login

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