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. Event queue processed upon calling QWidget::setEnabled()
Forum Updated to NodeBB v4.3 + New Features

Event queue processed upon calling QWidget::setEnabled()

Scheduled Pinned Locked Moved Unsolved General and Desktop
8 Posts 4 Posters 726 Views 1 Watching
  • 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.
  • F Offline
    F Offline
    Fbrxa
    wrote on last edited by
    #1

    I have a complex GUI application with several widgets displayed in differnet tabs and a worker thread for longer background jobs. Depending on what the worker is doing, it may sent a signal to some widgets to disable them until the job is done. The slot which does this, e.g. in widget "XY", contains a code like this:

    qDebug("Debug output before disabling widget XY");
    setEnabled(false);
    qDebug("Debug output after disabling widget XY");

    When the above code is executed, I see (in the debug output and the reaction of the GUI) that upon calling 'setEnabled(false)', the event queue of widget XY is processed (which is at that moment not empty and takes a few seconds). This is visible from the debug output of the other events in the queue which appears in between the above two debug messages, and further, widget XY remains enabled for the time the event queue needs to be processed. Widget XY behaves exactly as if 'qApp->processEvents()' had been called before 'setEnabled(false)'.

    I can trigger this behavior also be calling functions like 'setVisible()' instead of 'setEnabled()', but not with other functions like 'setToolTip()'. In a simple test tool I was not able to reproduce this procession of the event queue.

    Can you think of any situaltio in which the procession of the event queue is triggered upon calling the function 'setEnabled()'?

    I'd be grateful for and hint or comment on what could happen here!

    jsulmJ 1 Reply Last reply
    0
    • F Fbrxa

      I have a complex GUI application with several widgets displayed in differnet tabs and a worker thread for longer background jobs. Depending on what the worker is doing, it may sent a signal to some widgets to disable them until the job is done. The slot which does this, e.g. in widget "XY", contains a code like this:

      qDebug("Debug output before disabling widget XY");
      setEnabled(false);
      qDebug("Debug output after disabling widget XY");

      When the above code is executed, I see (in the debug output and the reaction of the GUI) that upon calling 'setEnabled(false)', the event queue of widget XY is processed (which is at that moment not empty and takes a few seconds). This is visible from the debug output of the other events in the queue which appears in between the above two debug messages, and further, widget XY remains enabled for the time the event queue needs to be processed. Widget XY behaves exactly as if 'qApp->processEvents()' had been called before 'setEnabled(false)'.

      I can trigger this behavior also be calling functions like 'setVisible()' instead of 'setEnabled()', but not with other functions like 'setToolTip()'. In a simple test tool I was not able to reproduce this procession of the event queue.

      Can you think of any situaltio in which the procession of the event queue is triggered upon calling the function 'setEnabled()'?

      I'd be grateful for and hint or comment on what could happen here!

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

      @Fbrxa said in Event queue processed upon calling QWidget::setEnabled():

      and takes a few seconds

      Few seconds?!
      What events are those and why does it take so long to process them?

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

      1 Reply Last reply
      0
      • F Offline
        F Offline
        Fbrxa
        wrote on last edited by
        #3

        These events are mainly log output written into the log file of the tool. The log output is sent by the worker thread. It is sometimes a lot of output, so the event queue is kept busy for one or two seconds.

        jsulmJ 1 Reply Last reply
        0
        • F Fbrxa

          These events are mainly log output written into the log file of the tool. The log output is sent by the worker thread. It is sometimes a lot of output, so the event queue is kept busy for one or two seconds.

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

          @Fbrxa said in Event queue processed upon calling QWidget::setEnabled():

          The log output is sent by the worker thread. It is sometimes a lot of output, so the event queue is kept busy for one or two seconds.

          Then maybe you should put logging into another thread?

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

          1 Reply Last reply
          0
          • F Offline
            F Offline
            Fbrxa
            wrote on last edited by
            #5

            True, but it would not solve the main problem, which is the premature procession of the event queue. It processes, e.g., also the signal sent to enable the widget, before the disabling is processed.

            Of course, I can rearrange the code here such that the I have the right sequence of procession in the main thread, but I would like to generally understand why a procession of the event queue is triggered here.

            1 Reply Last reply
            0
            • hskoglundH Offline
              hskoglundH Offline
              hskoglund
              wrote on last edited by
              #6

              Hi, maybe try another approach to silence/"neuter" your widgets during your background jobs:

              qDebug("Debug output before disabling widget XY");
              blockSignals(true);
              qDebug("Debug output after disabling widget XY");```
              

              blockSignals() is more lightweight and takes effect directly, but there's no visual indication that the widget is neutered. Maybe you can live with that...

              F 1 Reply Last reply
              0
              • JoeCFDJ Offline
                JoeCFDJ Offline
                JoeCFD
                wrote on last edited by
                #7

                qDebug("Debug output before disabling widget XY");
                setEnabled(false);
                QApplication::processEvents(); <==== try this one out to see if it helps.
                qDebug("Debug output after disabling widget XY");

                1 Reply Last reply
                0
                • hskoglundH hskoglund

                  Hi, maybe try another approach to silence/"neuter" your widgets during your background jobs:

                  qDebug("Debug output before disabling widget XY");
                  blockSignals(true);
                  qDebug("Debug output after disabling widget XY");```
                  

                  blockSignals() is more lightweight and takes effect directly, but there's no visual indication that the widget is neutered. Maybe you can live with that...

                  F Offline
                  F Offline
                  Fbrxa
                  wrote on last edited by
                  #8

                  @hskoglund 'blockSignals(true)' works, this function does not trigger procession of the event queue. Thank you for this suggestion!

                  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