Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
GetOpenFilename hangs forever given the dir of "D:\Downloads"
Using Qt 5.0.1:
//Using D:\downloads as the open file string hangs the process forever.
QString theFname = QFileDialog::getOpenFileName( this, "open the file", "D:\Downloads" );
ChrisW67 last edited by
Congratulations. You will need to define "hangs" and "forever" and explain what you have done to debug this before anyone can do whatever it is you were expecting them to do.
Serenity last edited by
What is content of the folder?
tzander last edited by
Does the D drive exist? Is this Windows?
Yeah, this needs much more info!
Jeroentjehome last edited by
Hi, Does your debugger work at all? When debugging my OpenFile is slow and very time consuming! So define "hangs" and "forever" ;-)
b1gsnak3 last edited by
You should use QFileDialog::getOpenFileNames if you want to select a directory... Also this opens a dialog in which you should select a directory from the default directory set in "D:/Downloads"
So I think I figured it out. The D:\Downloads folder has a lot of files in it and QT has something that crawls it then responds on the UI thread with information. I believe the issue is somewhere in here.
The hang is for like 30 secs to a minute on my machine the first time I open the directory.
Violet Giraffe last edited by
I've also noticed that native file dialog takes some time to open up on Windows for the first time. I believe this has to do with Windows/Explorer rather than Qt. Just my speculation, though.
This is true but it never takes 30 seconds to minutes. Furthermore if the open dialog is pointed towards a directory with just a few files this time is dramatically shorter meaning the dialog is pretty sensitive towards the number of entries in a directory.
Hmm, that line of reasoning certainly isn't bulletproof, but the file viewer's database backend is being filled by some sort of file scanning algorithm. If it was just the base window's implementation then I wouldn't expect that QT would run a background thread to scan the files. In any case, I am fairly certain (but not 100%) the problem lies in QT not the window's file viewer implementation.