PDA

View Full Version : QProgressDialog cancel signal is emitted always



Momergil
30th January 2013, 13:43
Hello!

I add a QProgressDialog in my project that shows a charge-and-calculate progress. After the process is complete, the QProgressDialog is supposed to be closed and deleted. But there is the possibility that the user might want to cancel the process, so I connected a slot to QProgressDialog's cancel() signal, so whenever the cancel() signal is emmited while clicking in QProgressDialog's Cancel button, the QProgressDialog is closed and deleted, and when its not, it is closed and deleted normally after the charge-and-calculate process is complete.

Doing so, I found that the cancel() signal is beeing emitted by QProgressDialog even when the Cancel button is NOT triggered, that is, when the user allows the progress normally to its end. SO what happens is that my software crashes, since it tries to do a close() and delete in the normal code while the erroneos cancel slot had already done that before due to this erroneos cancel emited signal.

Could this be a bug in Qt?

Personally I see no problem in my code, it's quite simple:



progressBarCarregaAtivos = new QProgressDialog(this);
progressBarCarregaAtivos->setWindowTitle("Loading...");
progressBarCarregaAtivos->setMinimum(0);
progressBarCarregaAtivos->setMaximum(filesNames.size());
progressBarCarregaAtivos->setLabelText("Loading shares data...");
progressBarCarregaAtivos->setWindowModality(Qt::ApplicationModal);
connect(progressBarCarregaAtivos,SIGNAL(canceled() ),this,SLOT(slotProgressBarCanceled()));
progressBarCarregaAtivos->show();



void MainWindow::slotProgressBarCanceled() //being called even when Cancel is not triggered
{
/*!
\brief chamado caso se aperte em "cancelar" quando esta sendo feito
o download em modo local. */
qDebug() << "Cancelou carregamento de ativos";

timerCarregaVarios->stop();
progressBarCarregaAtivos->close();

SAFEDELETE(timerCarregaVarios);
SAFEDELETE(progressBarCarregaAtivos);

counter_carregaVarios = 0;
carregaAtivosMux = 0;

filesNames.clear();
vetor_ativos.clear();

Flags.start_automation = false;
ui->actionStop_automation->setDisabled(false);
ui->actionAnalyse_a_share->setDisabled(false);
ui->actionReviewWindow->setDisabled(false);
ui->actionAlarms->setDisabled(false);

slotMemoLog("Carregamento local cancelado.","","\n");
}



//Normal end code
timerCarregaVarios->stop();
SAFEDELETE(timerCarregaVarios); //???

disconnect(progressBarCarregaAtivos,SIGNAL(cancele d()));
progressBarCarregaAtivos->close();
SAFEDELETE(progressBarCarregaAtivos)

Santosh Reddy
30th January 2013, 14:56
What is SAFEDELETE?

Anyway deleting the sending object in a slot is not safe, so instead use deleteLater()

progressBarCarregaAtivos->deleteLater();

d_stranz
30th January 2013, 16:05
Make a "proof of concept" project containing nothing except a plain, old, QDialog with a button that posts another QDialog. Connect slots to the OK and cancel signals and prove to yourself that there is no bug in Qt.

If this works as you would expect it to, then start looking for the bug in your own code which causes the unexpected behavior. If it doesn't work, then post that code here for review.

You should be able to do this in less than 20 lines of code.

(My hunch: It looks like you have a timer in your code. I would bet that the error lies in the handling of the timeout signals).

Momergil
31st January 2013, 03:24
What is SAFEDELETE?

Anyway deleting the sending object in a slot is not safe, so instead use deleteLater()

progressBarCarregaAtivos->deleteLater();

Hello Santosh,

I tried deleteLater, same problem. In fact, first I thought that SAFEDELETE was doing the problem, but after the change I noticed that it could be something else, an than I found the wrong cancel signal being emitted.



#define SAFEDELETE(_P) if(_P) {delete _P; _P = NULL;}


d_stranz, OK I'll see about it, but as I tried to say, no way I call cancel() for the QProgressDialog at least not if Ctrl+Shift+F is working properly!

Edit: noticed that "progressBarCarregaAtivos->close();" in the second code part I show? Well, I discovered that if I comment that close(), the signal cancel() is not wrongly emitted. And I also discovered that it's not necessary to call that close() because the QProgressDialog is closed even without any call to it's close(). I guess it's because of the autoReset/autoClose issue.