QFileDialog::getOpenFileName() hangs in Windows when using the native dialog

[SGaist]

Which compiler are you using ? Just tested with VS2013 on Win 8 and no problem with the dialog.

[GirishJ]

Facing exactly same problem on Windows 7 pro (64-bit) with Qt5.5 MSVS2010 Professional with Qt Add-in.

[mrjj]

win 7. 64 bit, Qt 5.5, "gcc"
No hanging at all.
So maybe only VS?

Please Try with QFileDialog::DontUseCustomDirectoryIcons
As i had case where it would take ages due to subversion overlay icons.

[Rondog]

I have used most of the Qt versions mentioned in this thread and never had a problem with using the getOpenFileName(...) member function with native dialogs. I have always used MinGW for Windows so maybe this problem is unique to Visual Studio?

[Wesley]

@SGaist said:

Do you have any network drive ?

I have a problem using the functions QFileDialog::getSaveFileName and QFileDialog::getOpenFileName on a PC with many network drives. Could you please help on this? Thanks.

[dan-42]

Just to note this issue still exists, but does not happen on all QFileDialogs instances used in our software.

When does it work:

On the very first start-screen, when no other backend-threads are running, no COM connection is created etc.

When does it not work

Some where later in the application, when backend-threads are running, COM connection to a different application is established.

Setup:

Qt 5.12.3
MSVC 2017 v15.9.7
Windows 10 build1809

The issue is reproducible on different computers in Debug and Release Build

Observations

Opening The QFileDialog leads to the following:

The Main-UI is blocked and you can hear the windows-sound that comes, when the UI is blocked because a Dialog is in front and the user clicks somewhere on the Main-UI.

Then

Switching between applications (Alt-Tab) then hitting ESC, and the Main-UI is responsible again.
This indicates, that there is an invisible Dialog on top of the main-UI.

Opening The QFileDialog again

Then it works!

[Gwen5484]

Same symptoms here, with QFileDialog::getExistingDirectory.

• Before loading the COM objets, the dialog opens well, with native window.
• After laoding COM (CoInitializeEx), calling getExistingDirectory causes the program to hang.
• After disconnecting COM (CoUninitialize), the dialog opens well again, but with Qt window (not native) even though I did'nt specify the DontUseNativeDialog option!

Qt 5.12.1, MSVC 2017, Windows 10

[JonB]

Clearly nasty COM behaviour. I am not a Qt expert, but since your post and the previous one are nice and clear on the reproducibility, the best would be to (search first and then) report them at https://bugreports.qt.io/secure/Dashboard.jspa, see also https://wiki.qt.io/Reporting_Bugs.

[Vortex0911]

Yeah I am encountering the same problem in 2024. This condition is also caused by QSplitter for some reason. Setting my "central" widget to QSplitter just causes it to permanently block a thread for some reason. But somehow setting the don't use native dialog option allows me to open it. If you have some suggestion for me do tell as I am a complete noob

[Richard]

We encountered this problem years ago. And this was caused by programs from DELL, "Dell Backup and Recovery", "Dell Optimizer", "Dell Power Management". These programs use Qt too, even statically compiled, but in a nasty way that prevented using newer Qt versions. And it crashed our software when you open a file dialog using native dialog on windows. Problems were solved once these programs were uninstalled.