In the bug report you write that "have to edit what I reported here before is wrong method. So the right method is getOpenFileNames. I am apologized." Of course, you should have updated your post here. More often than not, a problem is not in the API, but new conditions (such as new OS version) that expose a problem in how you use it. And you don't tell anything about it.

Hi, Just a recommendation: you should put a note in your code about that requirement otherwise there will likely be someone in the future (yourself included) that will wonder why there's that ! char there.

Hi, there is https://doc.qt.io/qt-5/qfiledialog.html#setSidebarUrls, is that what you want?

@JonB Thanks for your insight. I did as you suggested and found one of my local variable's address a nullptr(though not sure where it came from). I changed a few lines of code and apparently, my code works fine now. @Christian-Ehrlicher @J-Hilk thanks!

I don't know. You need to set the dialog to be "ApplicationModal" or set "modal" property: https://doc.qt.io/qt-5/qdialog.html#modal-prop

@mrjj I read it from the qt source code. I always do that when I want to cheat by using findChild / findChildren, to make sure I can find the right object.

@Mr-Workalot But what location do you need? Where do you want to store the file? It is really not clear from your description. Did you check the link I provided: https://doc.qt.io/qt-5/qstandardpaths.html ? Example: to store in Documents folder call https://doc.qt.io/qt-5/qstandardpaths.html#writableLocation with QStandardPaths::DocumentsLocation as parameter

@jsulm Looks like that is the only way to get the scaled widget correctly. Thanks!

@Bonnie said in QfileDialog::Getopenfilename does not open the second time and after: Remove that static. Static local variables Variables declared at block scope with the specifier static or thread_local (since C++11) have static or thread (since C++11) storage duration but are initialized the first time control passes through their declaration (unless their initialization is zero- or constant-initialization, which can be performed before the block is first entered). On all further calls, the declaration is skipped. So with the static keyword, getOpenFileName will only be called at the first time. Thanks! I just realized that I should not have copy pasted that line of code without looking at it closer. Cheers.

@mahesh_j said in File Browser with context menu to unzip files: But I don't know what actions to add to the QMenu The actions you need. You have to create such a pop-up menu. Take a look at http://quazip.sourceforge.net/

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