QMessageBox show() not displaying text

mzimmers

@mrjj said in QMessageBox show() not displaying text:

Well if it takes more than 1 sec before the containing slot is called again then is it then not true that timer.isActive() is false?

If it takes more than 1 second (which it never does), the isActive should report false, and a new singleShot should be called. At least that's what I'm attempting to do.

also the single shot might not even set active. maybe only start() does.
(just speculating)

Interesting...I'll replace the singleShot with a conventional timer and report back.

kshegunov

singleShot is a static function, it calls setSingleShot(true) and then start(). As this function doesn't really require an object it also does not modify your object in any way, effectively you're calling QTimer::singleShot.

PS.
Use like this:

timer.setSingleShot(true);
QObject::connect(&timer, &QTimer::timeout, this, &WhateverYourClassIsNamed::sendDiscoveryRequest);
// ...
if (devState == RESETTING)  {
    if (timer.isActive()) // only do one at a time.
        qDebug() << "\t\ttimer already queued.";
    else  {
        timer.start(1000);
        qDebug() << "\t\tqueueing timer.";
    }
}

mzimmers

OK, I found why the timer wasn't working for me. It turns out I defined the QTimer * variable twice: once as a member of my Worker class, and once again in the Worker constructor. General hilarity ensued.

I'm not saying this wasn't my fault, but I'd have expected the damn compiler to at least give me a warning when I did this.

Thanks to all for the help on the QTimer. Now that my communications sequence is intact, I can review my approach to the original problem with the QMessageBox. I'll report back when I have something.

kshegunov

@mzimmers said in QMessageBox show() not displaying text:

I'm not saying this wasn't my fault, but I'd have expected the damn compiler to at least give me a warning when I did this.

Not a thing that warrants a warning. Shadowing is a normal feature of the language, and you can see it quite a lot in my code. Without this I'd get a ton of warnings for correct usage of a valid language construct. For example for a generic QObject subclass (a situation that happens all the time):

class MyClass : public QObject
{
public:
    MyClass(QObject * parent = nullptr) //< `parent` shadows QObject::parent()
        : QObject(parent)
    {
    }
};

Or even more elaborate:

void QMpiCompoundRequestPrivate::requestFinished(QMpiRequest * child)
{
    if (!subrequests.remove(child))
        return;

    Q_Q(QMpiCompoundRequest);
    emit q->finished(child);
    if (subrequests.size() == 0)
        emit q->QMpiRequest::finished();
}

See how the second signal emission is done. That's because in the derived class (QMpiCompoundRequest) there's a function that shadows the base class' (QMpiRequest) method (even though with different set of parameters). So in this case you must be explicit which function exactly you're calling.

mzimmers

@kshegunov thanks for the explanation. I had never seen shadowing before, probably because I'd done very little work with derived classes. Good stuff to know going forward.