Hi, One base rule: all GUI manipulation must be done in the main thread (well the one that started the QApplication event loop).

@GrahamLa Where and when do you call func()?

you are looking at the strace output in real time Not really. - I would start such program tracing only after a personal delay to notice that data processing for the function “QFileDialog::getOpenFileName” might take longer than what I would usually expect. (I might be more patient under other circumstances.) what you would see is the last line of output would "hang" This did not happen. The dialogue software might be still busy with other stuff. Additional activities might distract then from temporary technical difficulties. just as you went into a "delay", and that would be your indication as to why.... I found questionable software behaviour also for other components in the suggested way so that corresponding clarification requests and bug reports were published.

@Hcf134 Maybe you should first call dialog.setMimeTypeFilters(mimeTypeFilters); and then dialog.selectMimeTypeFilter(selecttype);

I am using Qt 5.10.1, on CentOS 7

@SGaist Thank you for answer. From your suggestion, I need to create my own Dialog box.

@SGaist void DisplayDlg::on_pushButtonLoad_clicked() { QString fileName = QFileDialog::getOpenFileName(Q_NULLPTR, tr("Open Overlay"), "", "XML (*.xml)"); //This line crashes sometimes. Haven't seen it crash if I add option DontUseNativeDialog. ... } mfc140d.dll!000007fec6f97e0c() Unknown mfc140d.dll!000007fec6f5342c() Unknown mfc140d.dll!000007fec6f52832() Unknown user32.dll!0000000076ed9bdd() Unknown user32.dll!0000000076ee6189() Unknown user32.dll!0000000076ee4ea7() Unknown user32.dll!0000000076ee4f36() Unknown user32.dll!0000000076ee4f6c() Unknown comdlg32.dll!000007feff1628e8() Unknown qwindowsd.dll!000007fec494e5d1() Unknown qwindowsd.dll!000007fec495b823() Unknown qwindowsd.dll!000007fec495b7a5() Unknown Qt5Widgetsd.dll!00000000650ca1d2() Unknown Qt5Widgetsd.dll!0000000065048a8e() Unknown Qt5Widgetsd.dll!0000000065048920() Unknown MYDLL.dll!DisplayDlg::on_pushButtonLoad_clicked() Line 683 C++ MYDLL.dll!DisplayDlg::qt_static_metacall(QObject * _o, QMetaObject::Call _c, int _id, void * * _a) Line 128 C++ MYDLL.dll!DisplayDlg::qt_metacall(QMetaObject::Call _c, int _id, void * * _a) Line 184 C++ Qt5Cored.dll!000000006715df44() Unknown Qt5Cored.dll!00000000671a5e04() Unknown Qt5Cored.dll!00000000671a5488() Unknown Qt5Widgetsd.dll!0000000064fe877d() Unknown Qt5Widgetsd.dll!0000000064fea8b4() Unknown Qt5Widgetsd.dll!0000000064fe9977() Unknown Qt5Widgetsd.dll!0000000064fe8f37() Unknown Qt5Widgetsd.dll!0000000064cd695d() Unknown Qt5Widgetsd.dll!0000000064fe89cb() Unknown Qt5Widgetsd.dll!0000000065006011() Unknown Qt5Widgetsd.dll!0000000064c76f3e() Unknown Qt5Widgetsd.dll!0000000064c7217c() Unknown Qt5Cored.dll!000000006714f666() Unknown Qt5Cored.dll!00000000672b5cbb() Unknown Qt5Widgetsd.dll!0000000064c79633() Unknown Qt5Widgetsd.dll!0000000064d20e37() Unknown Qt5Widgetsd.dll!0000000064d1f60a() Unknown Qt5Widgetsd.dll!0000000064c76f3e() Unknown Qt5Widgetsd.dll!0000000064c71973() Unknown Qt5Cored.dll!000000006714f666() Unknown Qt5Cored.dll!00000000672b5cbb() Unknown Qt5Guid.dll!000007fedd97c19a() Unknown Qt5Guid.dll!000007fedd97ed13() Unknown Qt5Guid.dll!000007fedd939a45() Unknown qwindowsd.dll!000007fec499fe82() Unknown Qt5Cored.dll!000000006720ad0d() Unknown [External Code] MYAPP.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 26 C++ [External Code]

Hi and welcome to devnet, IIRC, you can select one or the other but not both at the same time.

@Armin You can use the static member function getOpenFileName

@Rondog @alex_malyu I see that this is not as simple as I had hoped and I guess I will just deal with using a directory browse or letting the user set the name. The reason i have the user interacting with an .ini is because it is not just global program settings that are loaded. I want the user to have multiple configurations that they can easily switch between that have file paths and numeric settings saved so that the program can be used easily in rapid succession. The GUI is a port of a console application that is not yet finished so I want debugging with it to be quick. This is why I have the ability to save and load a .ini file so that if a user keeps testing with the same paths over and over they don't need to keep browsing for the same files over and over again. However, I wanted there to be the ability to have multiple setups saved which is why I don't just want there to be one .ini that is used automatically. I know I could use some kind of slot system with the same .ini (like saves lots on a video game) to accomplish the same thing and the user just picks one of those slots. But like I said the application is not finished yet (the code behind the GUI) so it being perfectly clean is not an issue at the moment. Thank you for the information.

I figured it out. You can't call the connect statement for the doubleClick signal until the QListView is in scope.

@Devopia53 This did it with Windows. Thanks

I've tested on windows. It seems the only possible solution is to ignore native dialog. QFileDialog dialog; dialog.setFileMode(QFileDialog::DirectoryOnly); dialog.setOption(QFileDialog::DontUseNativeDialog, true); dialog.setOption(QFileDialog::ShowDirsOnly, false); dialog.exec(); qDebug() << dialog.directory();

Thanks! That did the trick. However, I had to delete each instance by hand, instead if using Qt::WA_DeleteOnClose, because I was referencing data from the dialog after it was closed.

Instead of editing the moc file you can just rebuild you project completely (you can delete the build folder before you rebuild).

I got it all working. I modified ololoepepe's class (http://stackoverflow.com/questions/12169878/limit-directory-traversal-in-qfiledialog) a bit for my pourposes and set the double click interval to 0 (essentially disabling double clicks). Thanks again.

One approach we used was to use the directoryEntered signal from the QFileDialog along with a custom proxy filter to handle it. The proxy contained a member variable for the last known good folder. Example code: void MyProxyModel::DirectoryEntered( const QString& Dir ) { QDir CurrentDir( Dir ); // If directory has no contents, reject the change. The isReadable() property is not reliable for some reason, as // it permits "opening" directories that the user has no permissions for (the result is no entries in the dialog). if( CurrentDir.entryList().size() == 0 ) { CurrentDir = m_LastGoodDir; m_pFileDialog->setDirectory( CurrentDir ); } m_LastGoodDir = CurrentDir; }

@Eyeless really sorry for the late reply! Just realised you have replied to me. After some testing I have solidified the conclusion that it is not a Qt problem, as was expected. As such, there is no reason to post my trivial dialog code. I am writing this for posterity's sake. This issue is caused due to the focus stealing prevention mechanism by Unity. The user could change Unity's default behaviour by issuing in a terminal the command: dconf write /org/compiz/profiles/unity/plugins/core/focus-prevention-level 0 This will allow for the consequent dialogs to appear in front of their parents, as expected.

Solved!! The problem was the paintEvent on the Qwidget CVWidget always running when I open an image. I suppose that it contrast the paintEvent of the QFileDialog with an incorrenct visualitazion.

@stefanq Super. Thank you for the feedback. Was not sure the linker flag would work with mingw. That is one mother of a texture :) Good luck

I forgot to double check but indeed it looks like that's the case