QFileDialog::getOpenFileName() hangs
https://forum.qt.io/topic/49209/qfiledialog-getopenfilename-hangs-in-windows-when-using-the-native-dialog/18
QFileDialog::getOpenFileName() hangs in Windows when using the native dialog
-
Hi,
I'm using QT 5.3.1 and I noticed that my program hangs in Windows 7 (64bit) with following arguments to the function.
QString fileName = QFileDialog::getOpenFileName(this, tr("Open File"),
"/home",
tr("Images (*.png *.xpm *.jpg)"));However, if I use the option QFileDialog::DontUseNativeDialog, then it won't hang and will show the non-native file open dialog. I would prefer to use the native windows dialog so can anyone tell me if this is a bug or not?
-
Hi and welcome to devnet,
Strange but are you aware that you are trying to open a probably non existent folder ? There's no /home on windows. However you can use QDir::home() to get the current user home path
-
Yes, this is just an example syntax for this post.
My syntax is as follows:fileName = QFileDialog::getOpenFileName(this,
tr("Select file"),
QString(),
tr("Files (*.cvs *.svf *.txt)"));
-
Do you have any network drive ?
-
-
No I don't. I just have a C:\ drive and couple of removable drives, which are not active.
This problem was reproduced on another PC other than mine.[quote author="SGaist" date="1418598787"]Do you have any network drive ?[/quote]
-
Which version of Windows ?
-
-
It is Windows 7 Professional (64bit).
Looking at the history of Qt, I think this possibly has been a bug for some time (possibly since QT4)....
I have seen at least 1 reported case of this sort of behaviour....[quote author="SGaist" date="1418678949"]Which version of Windows ?[/quote]
-
I have just recently migrated a project I am working on to Qt5.4.1 from Qt4.8.5, and I am having the same problem as reported by kasunf.
A call to getOpenFileName hangs - using QFileDialog::DontUseNativeDialog gets it working, but I'll prefer to use te native windows dialog. The code snippet is shown below:
m_imageFile = QFileDialog::getOpenFileName(this, tr("Open Image"), QDir::homePath(), tr("Image Files (*.png *.jpg *.bmp)"), 0, QFileDialog::DontUseNativeDialog); //works
m_imageFile = QFileDialog::getOpenFileName(this, tr("Open Image"), QDir::homePath(), tr("Image Files (*.png *.jpg *.bmp)")); //does not work
Program control does not seem to return from this function call. Has this issue been resolved? My system specifications are as follows:
Windows7 64bit
Visual Studio 2010
Qt5.4.1_openglPS: I did not have this problem with Qt4.8.5
Thanks,
-
Do you mean that when you click OK the dialog disappear but your application doesn't do anything ?
-
-
@SGaist Nope, that is not what I mean.
The open fIle dialog does not appear at all - as though my application is waiting for it to appear. After investigations it turns out that it seems to hang in the call to
QFileDialog::getOpenFileName(...)
As I indicated, a call to QFileDialog::getOpenFileName(...) using the flag QFileDialog::DontUseNativeDialog returns from the function call, but the same function call without using the flag does not return.
I will like to use it without the flag. Also, I didn't have this problem in Qt4.8.5.
Please this is the same problem as first reported on this post. I just need to know what the status of this issue is.
PS: I am interested in purchasing a commercial license for Qt5, but I need to make sure that my project works in Qt5 before going ahead with the purchase.
Thanks,
-
Which compiler are you using ? Just tested with VS2013 on Win 8 and no problem with the dialog.
-
Facing exactly same problem on Windows 7 pro (64-bit) with Qt5.5 MSVS2010 Professional with Qt Add-in.
-
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.
-
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?
-
@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.
-
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 build1809The 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!
-
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
-
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.