Cancel button on QProgressDialog is unresponsive - solved

Gryffster

Hi, I am using QProgressDialog to display the progress of a (potentially) long operation.

@

QProgressDialog cameraConnectProgressDialog("Connecting to Cameras", "Cancel", 0, 12, m_pParent );

cameraConnectProgressDialog.setWindowModality(Qt::WindowModal);

cameraConnectProgressDialog.setMinimumDuration(1);

while ( someBoolean && ( cameraConnectProgressDialog.wasCanceled() == false ) )
{
// Do some potentially time-consuming processing

    ...


    // Let the user know how many fails/successes are occuring

    std :: ostringstream labelStream;
    labelStream << "Cameras Connected: " << displayedStreams - failedCameras << " Cameras Failed: " << failedCameras;

    QString progressLabel( labelStream.str().c_str() );

    cameraConnectProgressDialog.setLabelText( progressLabel );       // Update the label
    cameraConnectProgressDialog.setValue(displayedStreams);         // Update the current value on the progress bar

    QApplication::processEvents( QEventLoop::AllEvents );              // Process events (I know AllEvents is the default.)

}
@

However, the Cancel button on the dialog is completely unresponsive. It doesn't respond to mouse press or release, and the dialog is not cancelled.

What am I doing wrong? In all other respects, the dialog operates as expected.

Thanks in advance

goblincoding

This might be a silly question, but did you connect the "Cancel" button's clicked signal to a relevant slot?

SGaist

Hi,

How long is your time consuming operation ? If it's really long, it will block the event loop so your dialog will be unresponsive.

You might have to refactor your time consuming operation to allow the event loop to run from time to time.

Gryffster

Goblin - initially I did connect the button to the slot, but then I read this in the documentation:

"This signal is emitted when the cancel button is clicked. It is connected to the cancel() slot by default."

Which I interpreted as meaning that the default behaviour is that on cancel being activated, the wasCanceled property is set to true (which can then be accessed via the wasCanceled() accessor) and the dialog is dismissed. It was my understadning that overloading cancel() allows you to tailor the behaviour, but in my case, I'm solely concerned with whether or not the cancel button was activated.

SGaist - the loop can take a few seconds, which is why I call QApplication::processEvents() each time around.

SGaist

In that case (IIRC), during the few seconds, the gui will be blocked. Can you split your task in smaller steps ?

goblincoding

[quote author="Gryffster" date="1366963766"]Goblin - initially I did connect the button to the slot, but then I read this in the documentation:

"This signal is emitted when the cancel button is clicked. It is connected to the cancel() slot by default."[/quote]

Oh, I see. Sorry for not being more useful! :)

Gryffster

You are right, I've added extra calls to processEvents() during the processing loop, and the cancel button is activated. For whatever reason, that single call to processEvents at the end of the processing loop wasn't able to process events quickly enough (?)

Thanks for your help!

Gryffster

Goblin - no problems, thanks for finding the time to reply.

SGaist

Great to see it works !

Don't forget to update the thread's title to solved so other forum users may know that a solution has been found :)

Gryffster

Will do