1

I'm trying to debug a c++/Qt5.5 code in MSVS2010 Professional. A function has following lines of code,

/* Static method approach */
QString filters("Music files (*.mp3);;Text files (*.txt);;All files (*.*)");
QString defaultFilter("Text files (*.txt)");

QFileDialog::getSaveFileName(0, "Save file", QDir::currentPath(), filters, &defaultFilter);

The dialog is simply doesn't open and the application freezes.

I tried the alternative was as below.

/* Direct object construction approach */
    QFileDialog fileDialog(0, "Save file", QDir::currentPath(), filters);
    fileDialog.selectNameFilter(defaultFilter);
    fileDialog.exec();

But again, the code freezes at 'fileDialog.exec()'. So, I created a different new simple project with these statements only and the it worked as expected.

Is this a issue of my environment configuration. I tried to debug but on stepping into the above line simply freezes the code without any error.

Vertexwahn
  • 7,709
  • 6
  • 64
  • 90
gaj
  • 317
  • 6
  • 20
  • Does it also happen when you provide a valid parent to the dialog instead of the 0 as the first parameter? – Bowdzone Aug 13 '15 at 08:59
  • yes, another observation is if I copy paste the same code right at the start of mainwindow initialization it works as expected. But it doesn't work in a mainWindow method. – gaj Aug 13 '15 at 09:08
  • can you provide more code? I have tried both snippets and they are working fine. – Alexander Tyapkov Aug 13 '15 at 09:43
  • 1
    Getting a deadlock for these shell dialogs is not unusual. It will happen when the thread that displays it is not an STA thread. Or if you have misbehaving shell extensions installed on the machine. There's nothing whatsoever in the question that provides a lead, a stack trace of the hung UI thread is a minimum requirement. – Hans Passant Aug 13 '15 at 11:56
  • Try changing it to a class member that lives longer than your automatically storage duration. The way `exec()` messes with the event queue is very confusing. – user3528438 Aug 13 '15 at 13:12

2 Answers2

4

This looks like a know issue in Qt. https://forum.qt.io/topic/49209/qfiledialog-getopenfilename-hangs-in-windows-when-using-the-native-dialog/8

The workaround is to use QFileDialog::DontUseNativeDialog flag as below.

m_imageFile = QFileDialog::getOpenFileName(this, tr("Open Image"), QDir::homePath(), tr("Image Files (*.png *.jpg *.bmp)"), 0, QFileDialog::DontUseNativeDialog); //works

Thanks for the help though!

gaj
  • 317
  • 6
  • 20
  • doesn't work for me. https://stackoverflow.com/questions/64531794/qthread-closes-whenever-qfiledialog-called-after-migrating-from-pyqt5-to-pyside2. it still blocks other QThread forcing the app to blatantly close with little warning as "QThread destroyed" – greendino Oct 26 '20 at 06:07
2

I had the same problem and discovered this could be because of a bad COM initialization in your UI thread. If you have somewhere:

HRESULT hres = CoInitializeEx( 0, COINIT_MULTITHREADED );

It MUST be replaced by:

HRESULT hres = CoInitializeEx( 0, COINIT_APARTMENTTHREADED );

I think the native window is maybe using COM calls, and just sits here because of a deadlock.

Tigzy
  • 161
  • 2
  • 12
  • how to do this in python. I'm running out of answers https://stackoverflow.com/questions/64531794/qthread-closes-whenever-qfiledialog-called-after-migrating-from-pyqt5-to-pyside2 – greendino Oct 26 '20 at 06:14
  • @lone_coder if you are not using COM in python then it can't be the problem – Tigzy Oct 27 '20 at 07:06