single QProgressDialog button push produces two signals

[mzimmers]

@Christian-Ehrlicher good point, and I'll correct that. I don't think it has any bearing on this problem though, as this issue occurs the first time through the code.

[JonB]

@mzimmers
If you say relayTransferCanceled() is called twice, what is the value of m_fileTransferDialog second time? You can put a breakpoint to see it hitting delete m_fileTransferDialog;. So really it should crash on the second time (on the m_fileTransferDialog->close();), unless the calls have quite distinct m_fileTransferDialog;s?

[mzimmers]

@JonB that's exactly what it does -- crash on the second close() attempt.

In looking at the canceled() signal, I wonder if I should disconnect it from the default slot cancel() before I use it. I notice that closing the window also triggers the signal.

EDIT:

Tried the above, no help. I'm definitely doing something to cause this code to execute twice, but I sure don't know what it is. Here's the latest effort:

void Widget::showFileTransfer()
{
    m_fileTransferDialog = new QProgressDialog("Transferring file", "Abort Transfer", 0, 100, this);
    QObject::connect(this, &Widget::progressChanged, m_fileTransferDialog, &QProgressDialog::setValue);
    QObject::connect(m_fileTransferDialog, &QProgressDialog::canceled, this, &Widget::relayTransferCanceled);
    m_fileTransferDialog->show();
}

void Widget::relayTransferCanceled()
{
    emit transferCanceled();
    deleteProgressDialog(false);void Widget::deleteProgressDialog(bool success)
}
void Widget::deleteProgressDialog(bool success)
{
    QString title;
    QString text;

    if (success)
    {
        title = "File Transfer Complete";
        text = "The file transfer has completed.";
    }
    else
    {
        title = "File Transfer Did Not Complete";
        text = "The file transfer did not complete successfully.";
    }

    QMessageBox *qmb;

    qmb = new QMessageBox(QMessageBox::NoIcon,
                    title,
                    text,
                    QMessageBox::Ok,
                    this);
    qmb->exec();
    m_fileTransferDialog->close();
    delete m_fileTransferDialog;
    delete qmb;
}

[SGaist]

How many file transfert can you have ?

If several, you should reconsider your dialog and give it the capability to show information for more than one transfert.

[mzimmers]

Just one, and I want the dialog to block. The file transfer is for tranferring OTA firmware updates, so multiple concurrent transfers are unnecessary and would be prone to causing all kinds of trouble.

[JonB]

@mzimmers said in single QProgressDialog button push produces two signals:

@JonB that's exactly what it does -- crash on the second close() attempt.

Aha! OK, you didn't say that :)

So I presume when you hit each time the stacktraces don't reveal anything different?

[mzimmers]

@JonB: not until you get fairly deep:

[JonB]

@mzimmers
Can't read the full name in column Function. The second one is to do with Widget::deleteP... and QWidget::close, clue?

[mzimmers]

Sorry about that. The stack quickly enters Qt space, so I can't do much with it myself. Interesting, though, that the 2nd iteration shows my code on level 17 whereas the 1st one doesn't.

[JonB]

@mzimmers
So the second call to the slot is coming from your Widget::deleteProgressDialog() on line m_fileTransferDialog->close();

I know nothing about this, but does closing the dialog cause the QProgressDialog::canceled signal to be raised? Does unconnecting that signal prior to m_fileTransferDialog->close(); solve your problem? take a look at https://www.qtcentre.org/threads/53056-QProgressDialog-cancel-signal-is-emitted-always ?

Also, you are calling deleteProgressDialog() in your relayTransferCanceled() slot. Should you/is it safe to be going

    m_fileTransferDialog->close();
    delete m_fileTransferDialog;

from a slot? Should it be more link deleteLater()?

These are just thoughts for you! I know nothing... :)

[mzimmers]

Hi Jon - all good suggestions, and all appreciated. I don't know of any reason I can't delete from a slot, but I did convert it to deleteLater().

I thought I'd already tried your suggestion to use disconnect() without success, but I tried it again, and now it seems to work.

void Widget::showFileTransfer()
{
    m_fileTransferDialog = new QProgressDialog("Transferring file", "Abort Transfer", 0, 100, this);
    QObject::connect(this, &Widget::progressChanged, m_fileTransferDialog, &QProgressDialog::setValue);
    QObject::connect(m_fileTransferDialog, &QProgressDialog::canceled, this, &Widget::relayTransferCanceled);
    m_fileTransferDialog->show();
}

void Widget::relayTransferCanceled()
{
    QObject::disconnect(m_fileTransferDialog, &QProgressDialog::canceled, nullptr, nullptr);
    emit transferCanceled();
    deleteProgressDialog(FILE_TRANSFER_CANCELED);
}

I'd like to get to the bottom of this issue, so I'm going to leave it as unsolved for a few days, but at least I have a workaround. Thanks.

[mzimmers]

I think I may have found at least part of the problem. It seems that my call to close() emits the canceled() signal, which was getting me in trouble, as my slot wasn't prepared for a signal under these circumstances. I guess I'm not supposed to call close(), which is actually a slot.

My app seems to be working now. I'm going to keep this unsolved for another day, just in case someone has something else to add.

So