QProgressDialog does not take input unless the progress value changes

JonB

@JanLaloux
I'm not really with you, but if you are periodically "polling" wasCanceled(), you should not be, you should be connected to the canceled() signal? So if you use that does it work?

JanLaloux

No, same problem.
But what's wrong with calling wasCancelled()? Docs: "This property holds whether the dialog was canceled"
Forgot to tell: Qt 6.5.2 for C++ on Windows

JonB

@JanLaloux
The question is when it gets set. Did you try the signal to see whether it works in your situation, then you would know whether that is the issue?

Christian Ehrlicher

When you block the event loop - how should the ui be redrawn? Use the canceld() signal and don't block the event loop...

SimonSchroeder

At some point the mouse events need to be processed. For this the event loop needs to run. It is very likely that you are blocking the event loop. There might be some weird behavior when calling setValue with a different progress that uses some direct connection to update the progress bar and also somehow processes the mouse event.

As a quick test you can call QApplication::processEvents() right before your call to wasCanceled() to see if this solves your problem. If it does you are definitely blocking the event loop. However, don't use this trick as your final solution. Your current loop will take about 100 times longer if you do this. It is not worth to slow down your actual processing by 100x just to have a nice UI.

Instead, then your solution should be to use a separate worker thread. You are not allowed to call any UI functions from the worker thread: no call to wasCanceled and no call to setValue. Instead you need to use signals and slots to connect these function calls.

andrewmorgan

@JanLaloux You’re right! Manually incrementing and resetting the progress value is not ideal. A cleaner approach could be calling QCoreApplication::processEvents() inside your loop to allow UI events (like button clicks) to be processed without artificially changing the progress value. You might also try setAutoReset(false) or setMinimumDuration(0) to see if it improves responsiveness.

JonB

@andrewmorgan
It would not be ideal to call processEvents(). It would be better to allow the main event loop to run and raise and act on the canceled() signal, as previously written.

JanLaloux

Thanks all for the valuable input!

@SimonSchroeder: the test with QApplication::processEvents() is positive, the problem goes away.
BUT: the implementation is as documented for the QProgressDialog Class for the modal operation:
"Compared to a modeless QProgressDialog, a modal QProgressDialog is simpler to use for the programmer. Do the operation in a loop, call setValue() at intervals, and check for cancellation with wasCanceled(). "
So with the functions, not the signals.
And since it is the intention that the user cannot do anything than either wait for the operation to finish, or to cancel it, this seems to me correct for the modal operation?

Pl45m4

@JonB said in QProgressDialog does not take input unless the progress value changes:

It would not be ideal to call processEvents()

The only valid use case for processEvent() to update the progress of QProgressDialog/ QProgressBar is when using it in combination with tasks that run in main.cpp before the event loop is even started or like everything QSplashScreen related...

Christian Ehrlicher

@JanLaloux said in QProgressDialog does not take input unless the progress value changes:

Compared to a modeless QProgressDialog, a modal QProgressDialog is simpler to use for the programmer. Do the operation in a loop, call setValue() at intervals, and check for cancellation with wasCanceled(). "
So with the functions, not the signals.

We should adjust the documentation... blocking the event loop is a bad idea.