after closing modal window, display is updated in the wrong order

[jwu]

cross posting from [URL="https://stackoverflow.com/questions/47740565"]stackoverflow:

The following C++/Qt code is used to launch a modal dialog that prompts for a file selection:


QFileDialog dlg(parent, caption, dir, filter);
dlg.setOption(QFileDialog::DontUseNativeDialog);
dlg.setViewMode(QFileDialog::Detail);
dlg.setAcceptMode(QFileDialog::AcceptOpen);
dlg.setReadOnly(true);
dlg.setProxyModel(new OpenFileProxyModel);
dlg.setFileMode(FileDialog::ExistingFiles);
if (dlg.exec())
return dlg.selectedFiles();

This is correctly executed. Then, however, the calling application proceeds to load the selected files, and updates a file list in the main window - before the modal dialog is properly closed. This results in a badly disfigured transient display. Part of the QFileDialog remain visible, while others are overwritten by updated parts of the main window.

How to prevent this behavior?

Other discussion threads suggest

qApp->processEvents();

which, however, has no effect here.

[high_flyer]

however, the calling application proceeds to load the selected files, and updates a file list in the main window - before the modal dialog is properly closed.
How do you know that this is what is happening - how do you know that the modal dialog is not "properly closed" - and even if ?
The very notion is very strange to me.
I believe something else is the problem, but without more code its hard to say.

To test you claim you could have the application load the selected files etc in a slot connected to the file dialog's destroyed signal.
If then it still behaved like that, then you know your theory was wrong.
If it works well, then you were right, and you have your solution - but that will surprise me, and would indicate a Qt bug.

Are you overriding the paintEvent() of your main window?
It looks more like something of this sort.

Try calling update() in your main window right after the file dialog closes see if this helps.

[d_stranz]

I have had dialogs "hang" (i.e. not disappear after closing) when the application does some heavy processing with the result returned by the dialog. If the dialog is invoked by a slot, and the slot goes on to do other things before returning to the event loop, the dialog can stay posted until that processing is done and the event loop resumes. Perhaps this is what you are seeing.