Dialogs no longer closing when another is active.

[Nate M]

Our project is upgrading from Qt5 to Qt6. There are multiple places where our applications will open a dialog, then another dialog will open over it, then close the first (using accept() or reject() ) while the second dialog is open. This no longer seems to be working, and the first dialog stays open. I've been able to change some ordering, so the first dialog closes before the second opens, or the closing of the second dialog triggers the first. However, I'm now running into cases where there are more dialogs, and it's turning into a sequencing mess. Is there some configuration that allows or dissallows accept() and reject() to close dialogs if they don't have focus?

Thanks!

[JonB]

@Nate-M said in Dialogs no longer closing when another is active.:

Is there some configuration that allows or dissallows accept() and reject() to close dialogs if they don't have focus?

For sure not.
You might want to supply some minimal example showing the changed behaviour.

[Nate M]

Here's how I fixed one of the issues. Here is the code that closes Dialog1 in Qt5, but in Qt6 leaves Dialog1 still open:

connect( ui.ui_buttonNew, &QPushButton::clicked, handler, &Handler::FunctionThatOpensDialog2 );
connect( ui.ui_buttonNew, &QPushButton::clicked, this, &Dialog1::reject );

To fix it, I just reversed the order, so that Dialog1 closes before the function that opens Dialog2:

connect( ui.ui_buttonNew, &QPushButton::clicked, this, &Dialog1::reject );
connect( ui.ui_buttonNew, &QPushButton::clicked, handler, &Handler::FunctionThatOpensDialog2 );

[SGaist]

You should rather have one slot that does all the work. It would be cleaner to maintain as well.

[Nate M]

Unfortunately, other instances that need fixing aren't as straightforward. Was there any changes between Qt5 and Qt6 that change how modal dialogs behave? For example, not allowing dialogs below to receiving signals, or not allowing them to accept/reject?

[SGaist]

I don't think so. However having event loops within event loops might have side effects and you could be experiencing that.

Hence my suggestion of keeping that kind of processing within dedicated slots.

[mpergand]

@Nate-M said in Dialogs no longer closing when another is active.:

There are multiple places where our applications will open a dialog, then another dialog will open over it, then close the first (using accept() or reject() ) while the second dialog is open.

Awfull design :(
If you have multi screens/dialogs to present one after the other,
use QWizard

[SimonSchroeder]

Well, here is my guess: First of all, I assume that your dialogs are all modal, and secondly that you use dialog.exec() to run them (which creates the nested event loops that @SGaist mentioned). If FunctionThatOpensDialog2 gets executed first and uses exec() it will not return before the new dialog closes. If Qt uses a direct call to FunctionThatOpensDialog2 instead of placing it into the event loop, I assume that the clicked() signal will not call reject() before FunctionThatOpensDialog2 returns.

If you need control over the order of execution (the order of the connects is not bullet proof) you have to follow the suggestion of @SGaist and use a dedicated slot (could be a lambda that calls the two functions in order).

Another thing you can try (derived from my guess above) is to add the parameter Qt::QueuedConnection to the connect calls. If you are lucky the exec() from FunctionThatOpensDialog2 will handle the queued reject() as well. (I am not 100% sure because of the modality of the second dialog.)