Event queue processed upon calling QWidget::setEnabled()

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

[jsulm]

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

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

[jsulm]

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

[Fbrxa]

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.

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

[JoeCFD]

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");

[Fbrxa]

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