2nd QInputDialog after QFileDialog immediately closes

LinusA

Hi,

I'm not sure whether this a bug in Qt or if I did something wrong, but I suppose it's the latter ;).

Basically, after I've used a combination of QInputDialog::getItem() and QFileDialog::getOpenFileName(), any following QInputDialog::getItem() dialogs will just pop up quickly and close immediately, while QFileDialog::getOpenFileName() still works as expected. What am I doing wrong? Any clues as how to debug it will be appreciated...

Here's my main method:
@
int main(int argc, char *argv[]) {
QApplication app(argc, argv);

CMain myMain(&app);
QTimer::singleShot(0, &myMain, SLOT(doMain()));

int returnVal = app.exec();
cout << "Press ENTER to exit..." << endl;
getchar();
return returnVal;
}//end main
@

It uses the CMain class. Header is here:
@
class CMain : public QObject {
Q_OBJECT

public:
CMain(QObject *parent);
~CMain();

public slots:
void doMain();

private:
};//end class
@

And the body with the problematic bit of code here (c'tor and d'tors are empty):
@
void CMain::doMain() {

QStringList myItems;
myItems << "Item 1" << "Item 2" << "Item 3";

// this all works!
QInputDialog::getItem(nullptr, "Test input 1", "Choose:", myItems);
QFileDialog::getOpenFileName(nullptr, "Open some file", QString(), tr("All files (.)"), nullptr, QFileDialog::ReadOnly);

// now, this dialog will pop up ("flash") and close immediately
QInputDialog::getItem(nullptr, "Test input 2", "Choose 2nd time:", myItems);

// this works again!
QFileDialog::getOpenFileName(nullptr, "Open another file", QString(), tr("All files (.)"), nullptr, QFileDialog::ReadOnly);

cout << "doMain() done. Time to quit()." << endl;
qApp->quit();

}//end method
@

I've uploaded the whole project as Visual Studio 2008 Solution (and I exported a .pro file from it). I'm on Windows 7 32bit, and using Qt 4.7.1. Here's the link: https://gigamove.rz.rwth-aachen.de/download/id/n25wbjrCjbGKrY

Thanks very much for looking into this! Best regards,
Linus

jim_kaiser

Could you try it by passing a parent ('this' in your case, instead of the nullptr)? Also, I see you have used a singleshot timer to run the doMain() function.. Could you put some time in this.. so that the slot is not executed before the app.exec() is called.. The exec() starts the event loop of the application..
Normally we show our widgets and then run app.exec() to start the event loop. Now, the application is setup to respond to user events. In your case, if you want to use a timer.

Try:
@QTimer::singleShot(2000, &myMain, SLOT(doMain()));@

LinusA

[quote author="jim_kaiser" date="1308316374"]Could you try it by passing a parent ('this' in your case, instead of the nullptr)?
[/quote]
Unfortunately, I can't. 'this' is just a QObject, while the pointer needs to be a QWidget. Do I need to upgrade my CMain class to be a QWidget? I mean, I'm just calling static methods, just like message-boxes, I don't see why I'd need a widget. And in fact, it does work right until the 2nd time.

When I debug the code, I see that the dialog's "show()" method is called, it pops up, and closes right away.

[quote author="jim_kaiser" date="1308316374"]
Also, I see you have used a singleshot timer to run the doMain() function.. Could you put some time in this.. so that the slot is not executed before the app.exec() is called.. The exec() starts the event loop of the application..
Normally we show our widgets and then run app.exec() to start the event loop. Now, the application is setup to respond to user events. In your case, if you want to use a timer.

Try:
@QTimer::singleShot(2000, &myMain, SLOT(doMain()));@[/quote]

Thanks, I just tried it, and it makes no difference.

I think I've read in a book (IIRC by Mark Summerfield) that you can use the time 0, and the "singleShot" will be scheduled right away when the event loop starts -- so that shouldn't be the problem.

However, is there a way to "start" my doMain() slot without the timer? So that the event-loop is running and I get the chance to execute code sequentially, just as I do now?

jim_kaiser

Hmm... you're right.. i guess the timer would execute at the start of the event loop..

As for running the slot without a timer.. well.. why not put a button and use doMain() as the slot for clicked..

Anyways, I will try and test this issue and get back to you..

LinusA

[quote author="jim_kaiser" date="1308317471"]
As for running the slot without a timer.. well.. why not put a button and use doMain() as the slot for clicked..
[/quote]
I created this project to demonstrate my problem. In my real "big" application, it's not clear from the start whether I need to show input dialogs at all. I check command line arguments, and if they're present, CMain does all the processing without user interaction. But if the command line arguments are missing, the parameters are retrieved via those static file and input dialogs. So I don't really have a main window or widget or anything. On the other hand, again: I don't see why this would cause problems...

Thanks for discussing this, it might help me to get the insight I need

LinusA

It gets worse. I experimented, and it seems that after a call to QFileDialog::getOpenFileName(), many (built-in) dialogs are somehow broken. I confirmed this for QMessageBox and QErrorMessage. Go ahead and change the code in doMain() to this:
@
void CMain::doMain() {
// check that the message box is working as expected!
QMessageBox::information(nullptr, "Test Msgbox", tr("Qt Version: %1").arg(QT_VERSION_STR));

// THIS QFILEDIALOG BREAKS SOMETHING!
// comment the next line out to see everything working normal!
QFileDialog::getOpenFileName(nullptr, "Open some file", QString(), tr("All files (.)"), nullptr, QFileDialog::ReadOnly);

// you'll hear the message box sound, but don't see anything
QMessageBox::warning(nullptr, "Test Msgbox 2", "Hi, I'm another msg box");

// the error msg will show up, but it will stay "unusable" in the background
// also the program will execute the following file dialog at the same time without waiting
QErrorMessage ErrMsg;
ErrMsg.setModal(true);
ErrMsg.showMessage(tr("This is some sort of error message"));
ErrMsg.exec();

// this pops up too early
QFileDialog::getOpenFileName(nullptr, "Open another file", QString(), tr("All files (.)"), nullptr, QFileDialog::ReadOnly);

cout << "doMain() done. Time to quit()." << endl;
qApp->quit();
}//end method
@

Comment out the first QFileDialog::getOpenFileName() where the comment suggest it. You'll see the expected behaviour. Now, enable that line, and watch every dialog (except another file dialog) "break" after that line. I've tested this on 2 different machines, both VS 2008, Qt 4.7.1, one Windows 7 32bit, the other WinXP SP3 32bit.