preventing excessive message boxes

mzimmers

Hi all -

My worker thread signals the widget thread to put up a message box when it fails to make a network connection. This is in a 3-second retry loop. Obviously, if the user doesn't keep up with dismissing these messages, they stack up pretty fast.

My first thought is for the widget to signal the worker when the message box is dismissed, and the worker won't create another message box until it receives this signal. Is this a reasonable way of doing it, or is there a more elegant solution?

Thanks...

mrjj

Hi
You could also use
https://doc.qt.io/qt-5/qwidget.html#visible-prop
in the " widget thread" to check if its currently showing and if it is, then simply return
from the function.

mzimmers

@mrjj I like that idea. Currently, I just create a new message box whenever I get the signal. I guess I could make it static (or a member object), and test its visibility whenever the widget receives the signal. Is that what you had in mind?

mrjj

@mzimmers
yes just make it a member.
Your idea was not bad either but if isVisible just works its more simple overall
and less that can break :)

JonB

@mzimmers said in preventing excessive message boxes:

My first thought is for the widget to signal the worker when the message box is dismissed, and the worker won't create another message box until it receives this signal.

IMHO, that seems an odd way round, conceptually. Widgets don't need to tell your worker thread about this. Worker thread should signal whenever it says something to say, like a network connection failure/timeout. It's up to the UI side only to decide what/when/how often to deal with these interacting with the user. "worker thread signals the widget thread to put up a message box" --- there shoudn't be a signal to "put up a message box", only a signal to say what has happened. Just saying.

If your solution with @mrjj handles it only at the UI side that is good.

mzimmers

@JonB agreed.

// in the class definition
    QMessageBox m_qmb;

// in the c'tor
    m_qmb.setIcon(QMessageBox::NoIcon);
    m_qmb.setVisible(false);

// the slot
void Widget::displayQmb(QString title, QString text)
{
    if (!m_qmb.isVisible())
    {
        m_qmb.setText(text);
        m_qmb.setWindowTitle(title);
        m_qmb.setVisible(true);
        m_qmb.exec();
        m_qmb.setVisible(false);
    }
}

JonB

@mzimmers
Code is fine. But would you like to consider concept?

As I understand it, you have a background thread trying to connect, and that can take time with retries. You first put up a modal message box when this happens.

Since you let the user dismiss this, presumably that's so he can carry on doing other things in the UI? Now either you put up the message box again next time, which will annoy him (I think that is what you have now got rid of), or you just let him carry on and he doesn't know about retries failures/successes?

I don't know your full app, but it sounds to me like some sort of status message on a status bar, or possibly a modeless/progress dialog showing the retries till success, would aid the user? You could even have made the dialog you are using now modeless for this purpose.

No reason you should adopt my suggestion, I just felt chatty :)

mzimmers

@JonB good point, and you got the user scenario mostly right. In this instance, the error message has to do with the inability to connect to a network, which is an exceptional event (at least it should be). Without that connection, the app is pretty much worthless -- there's no other work that the user can do.

So, for this case, I think the modal dialog is fine. If the user gets tired of seeing it, he can close the app and go bug his network admin.

Please feel free to disagree.

kshegunov

Consider buffering the messages so you could display 3-4-5 and so on errors at once at least. Your thread may be "prolific", you don't want it to show 5 message boxes when it needs to display just the one with all errors inside, do you? :)

mzimmers

@kshegunov very interesting idea. That's taking a step towards a persistent status area on the main display. Instead of popups, messages just get queued to this area.

Again, though, this particular error is so rare and so dire that it probably does warrant bringing the app to a screeching halt. At least IMO. (I probably should have mentioned this in my original post.)

Pablo J. Rogina

@mzimmers said in preventing excessive message boxes:

So, for this case, I think the modal dialog is fine.

You may also want to make the dialogs "auto-closable" after some timeout

kshegunov

@mzimmers said in preventing excessive message boxes:

@kshegunov very interesting idea. That's taking a step towards a persistent status area on the main display. Instead of popups, messages just get queued to this area.

Yes, mayhaps that's the correct decision, but as @JonB mentioned, we don't know your app and ultimately it's your decision. We can only bounce ideas off.

Again, though, this particular error is so rare and so dire that it probably does warrant bringing the app to a screeching halt. At least IMO. (I probably should have mentioned this in my original post.)

Yes, as the OP says "excessive message boxes", so we naturally try to suggest ways to mitigate that. ;)