Main thread waiting until dialog completion

mrjj

Hi
A better design is simply to emit a signal when dialog is finished.
Then main can do what task you plan.
Generally, you do not pause or make main tread wait
as it lags the app , prevent events flowing and
its just bad design.

Can I ask why you want to wait ?

HunterMetcalfe

I realize that. This particular event arises when multiple error messages are received. I handle each of those with a dialog as whether the user wants to continue or not. In the event that multiple errors occur I receive the warning "QDialog::exec: Recursive call detected"

The reason I would block or make the main thread wait is that nothing behind the scenes should be processed until the users input is received.

HunterMetcalfe

Really I'm trying to understand why the QDialog::exec: Recursive call detected is being outputted.

mrjj

@HunterMetcalfe
Hi
Yes me too.
You are not using threads ?

? Offline

Hi! The main responsibility of the main thread, aka GUI thread, is to handle both events from the OS and the GUI. If your application's design requires you to block the main thread, then your design is flawed.

HunterMetcalfe

Okay I figured out the solution. I will post the relevant code. Hopefully it helps others.

In the constructor I have

connect( singleton,
       SIGNAL( ErrorReceived( ErrorMsg ) ),
       this,
       SLOT( ErrorReceived( ErrorMsg ) ),
       Qt::BlockingQueuedConnection );

In my slot "ErrorReceived"

void Panel::ErrorReceived( ErrorMsg msg )
{
   m_errorDialog->exec();
}

The solution is to use a

Qt::BlockingQueuedConnection

This allows the user to work with the current dialog as to whether or not they want to continue. In the meanwhile future errors will queue. After completing, the next dialog will popup, while still allowing the main thread to receive updates.

@mrjj Yes this application is multi-threaded

HunterMetcalfe

@Wieland Thanks for the reply, I didn't word it entirely well, but I have posted my solution below.

mrjj

@HunterMetcalfe
Hi
so the "Recursive call detected" came from being inside dialog .exec() and then
a signal to open yet another Dialog comes and that is handled inside the current exec() ?

HunterMetcalfe

@mrjj Yes, that seemed to be the case. I had even tried disconnecting the slot from the signal while executing the dialog, then reconnecting, but that didn't fix the issue.

mrjj

@HunterMetcalfe
Hmm, that is a bit odd as how would it then open the dialog (again) but
i guess we will never really know. :)

HunterMetcalfe

@mrjj I also believed that would've been the functionality. Funny thing is now when the user clicks no on the dialog, I don't want anymore popups to be displayed. I considered doing a bool variable that tracks whether the user has clicked no, but it seems to need some more thought out logic.

So if( !no)

dialog->exec();

something like that.

mrjj

@HunterMetcalfe
Hmm
But when will you know that pop ups are ok again ?
You could use a timer, so if a new POP is seen X secs after user says no, they are ignored.

But it really depends when its ok again to popup after last "no"

HunterMetcalfe

@mrjj Yes, that's the trouble - determining when popups will be okay again.

mrjj

@HunterMetcalfe

Do the errors have any ID so you can know its from same batch ?

HunterMetcalfe

@mrjj No they don't but I was able to work around that using a flag in my singleton.