0

I'm trying to make a board game where the first thing the program does is it asks for the difficulty. I'd like to close the whole program if the user presses cancel. I'm doing:

GameWindow::GameWindow(QWidget *parent)
    : QWidget(parent)
{
    QList<QString> difficultyChooser;
    difficultyChooser << "Easy" << "Medium" << "Hard";
    QInputDialog *dialog = new QInputDialog();
    bool accepted;
    QString item = dialog->getItem(0, "New game", "Choose difficulty!", difficultyChooser, 0, false, &accepted);
    if (accepted && !item.isEmpty()) {
        if(item == "Easy") {
            _gameManager->difficulty = Easy;
        } else if (item == "Medium") {
            _gameManager->difficulty = Medium;
        } else {
            _gameManager->difficulty = Hard;
        }
     //setup window etc

    } else {
        this->close();
        QApplication::quit();
    }
}

This however, doesn't work: If I press Cancel, a blank window still appears. Why does this happen and how can I close the window/program if Cancel is pressed?

lte__
  • 7,175
  • 25
  • 74
  • 131
  • Have you tried simply calling `close()`? Wouldn't it be better to create the dialog before `GameWindow` and create `GameWindow` conditionally? – LogicStuff Jun 06 '17 at 12:53
  • Is `GameWindow` your main window? Anyway it might not work as expected because you do all the work (show dialog etc) in your constructor so the window is not fully created yet when you try to close it. – xander Jun 06 '17 at 12:59
  • In the future, please show the remainder of your code. We have to guess as to what you're doing wrong - the code you show certainly fulfills a necessary condition for it not to work, but it's not sufficient to be entirely sure how you messed up. Alas, I'll take my chances and declare this a duplicate. – Kuba hasn't forgotten Monica Jun 06 '17 at 13:26
  • 1
    @xander You've almost got the right idea. The real issue is that `quit` is called before `QCoreApplication::exec()` and is thus a no-op. Such problems are precipitated by the pseudo synchronous programming style where asynchronous tasks are interleaved with run-to-completion code. Reentering the event loop should be avoided at all costs - it leads to these kinds of problems, and those are about the simplest ones. One can spend an inordinate amounts of time debugging event loop reentrancy problems. It's best to prevent them by design. – Kuba hasn't forgotten Monica Jun 06 '17 at 13:28
  • @xander Yes, it's the main window. I'll try to delegate the dialog to another function outside the constructor, see if that works. – lte__ Jun 06 '17 at 13:41
  • It won't work as long as you're either directly or indirectly using `QDialog::exec` before `QCoreApplication::exec`. Instead of using `getItem`, you should configure the dialog, then `show()` it, then react to a signal from the dialog that indicates that a selection has been made. You live in an asynchronous world :) – Kuba hasn't forgotten Monica Jun 06 '17 at 13:45
  • It did work, I just checked :) – lte__ Jun 06 '17 at 13:46

0 Answers0