1.11.  Qt Dialogs for User Input/Output

[ fromfile: qtfirstapp.xml id: qtfirstapp ]

Example 1.15 shows a rewrite of the first C++ example, using standard Qt dialogs instead of standard input/output and QString instead of Standard Library strings. We include this example here, even though the code contains a few things that have not been discussed yet so that you can see another way to ask for input and present output, using Qt GUI convenience functions.

Example 1.15. src/early-examples/example1/fac1.cpp

#include <QtGui>

int main (int argc, char* argv[]) {                 1
    QApplication app(argc, argv);                   2
    QTextStream cout(stdout);                       3

    // Declarations of variables
    int answer = 0;                                 4

    do {
        // local variables to the loop:
        int factArg = 0;
        int fact(1);
        factArg = QInputDialog::getInt(0, "Factorial Calculator",
            "Factorial of:", 1);                    5
        cout << "User entered: " << factArg << endl;
        int i=2;
        while (i <= factArg) {
            fact = fact * i;
            ++i;
        }
        QString response = QString("The factorial of %1 is %2.\n%3")
            .arg(factArg).arg(fact)                 6
            .arg("Compute another factorial?");     7
        answer = QMessageBox::question(0, "Play again?", response,
            QMessageBox::Yes | QMessageBox::No);    8
    } while (answer == QMessageBox::Yes);
    return EXIT_SUCCESS;
}

1

Start of function "main" which returns int.

2

Start of every Qt GUI application.

3

Create a QTextStream to standard output.

4

Must be defined outside the do loop because it is used in the condition outside the do block.

5

Pop up dialog, wait for user to enter an integer, return it.

6

Each %n is replaced with an arg() value.

7

Long statements can continue on multiple lines, as long as they are broken on token boundaries.

8

Bitwise or of two values.


This program makes use of the Qt types (classes) listed next.

  1. QApplication – A single object that needs to exist in Qt GUI applications.

  2. QInputDialog – For asking questions of the user.

  3. QMessageBox – For sending responses back to the user.

  4. QString – A unicode string class. This example uses the powerful QString function arg(), which enables you to format parameterized values (%1, %2, etc.) into the string.

  5. QTextStream – For streaming to/from text files. In this example, we defined a variable called cout that goes to the same place (stdout) as the iostream cout from the C++ standard library. If you intend to get user input from dialogs and other widgets, there is no need for cin anymore.

The code in Example 1.15 contains items discussed in the next few chapters:

When you run this application, you first see an input dialog like Figure 1.2.

Figure 1.2.  QInputDialog – Getting an int

QInputDialog – Getting an int

The input "widget" inside the dialog box is called a spin box and is implemented as QSpinBox. It displays the current value and, if the user clicks on the up or down button located at the right end of the display space, it displays other acceptable choices. The user could also press the up or down arrow key. The implementation is flexible and can easily be customized (e.g., by specifying the minimum and maximum acceptable values). After the user enters a number and clicks OK, the dialog box is replaced with a QMessageBox that pops up with the calculated result.

Figure 1.3.  QMessageBox Question

QMessageBox Question

More About Project Files

Any application that uses Qt classes needs a project file. Recall that a project file describes the project by listing all of the files and all of the options and file locations that are needed to build the project. Because this is a simple application, the project file is also quite simple, as shown in Example 1.16.

Example 1.16. src/early-examples/example1/example1.pro

TEMPLATE = app
include (../../common.pri)
SOURCES += fac1.cpp

The first line, TEMPLATE = app, indicates that qmake should start with a templated Makefile suited for building applications. If this project file were for a library, you would see TEMPLATE = lib to indicate that a Makefile library template should be used instead. A third possibility is that you might have your source code distributed among several subdirectories, each having its own project file. In such a case you might see TEMPLATE = subdirs in the project file located in the parent directory, which would cause a Makefile to be produced in the parent directory and also in each subdirectory.

The second line includes the optional common project settings from Example 1.6. Finally, the source file is listed in SOURCES.