In this section, we will explain how to use dialogs in Qthow to create and initialize them, run them, and respond to choices made by the user interacting with them. We will make use of the Find, Go-to-Cell, and Sort dialogs that we created in Chapter 2. We will also create a simple About box.
We will begin with the Find dialog. Since we want the user to be able to switch between the main Spreadsheet window and the Find dialog at will, the Find dialog must be modeless. A modeless window is one that runs independently of any other windows in the application.
When modeless dialogs are created, they normally have their signals connected to slots that respond to the user's interactions.
void MainWindow::find() { if (!findDialog) { findDialog = new FindDialog(this); connect(findDialog, SIGNAL(findNext(const QString &, bool)), spreadsheet, SLOT(findNext(const QString &, bool))); connect(findDialog, SIGNAL(findPrev(const QString &, bool)), spreadsheet, SLOT(findPrev(const QString &, bool))); } findDialog->show(); findDialog->raise(); findDialog->setActiveWindow(); }
The Find dialog is a window that enables the user to search for text in the spreadsheet. The find() slot is called when the user clicks Edit|Find to pop up the Find dialog. At that point, several scenarios are possible:
If the Find dialog doesn't already exist, we create it and connect its findNext() and findPrev() signals to Spreadsheet's matching slots. We could also have created the dialog in the MainWindow constructor, but delaying its creation makes startup faster. Also, if the dialog is never used, it is never created, saving both time and memory.
Then we call show(), raise(), and setActiveWindow() to ensure that the window is visible, on top of the others, and active. A call to show() alone is sufficient to make a hidden window visible, but the Find dialog may be invoked when its window is already visible, in which case show() does nothing. Since we must make the dialog's window visible, active, and on top regardless of its previous state, we must use the raise() and setActiveWindow() calls. An alternative would have been to write
if (findDialog->isHidden()) { findDialog->show(); } else { findDialog->raise(); findDialog->setActiveWindow(); }
the programming equivalent of driving along at 90 in a 100 km/h zone.
We will now look at the Go-to-Cell dialog. We want the user to pop it up, use it, and close it without being able to switch from the Go-to-Cell dialog to any other window in the application. This means that the Go-to-Cell dialog must be modal. A modal window is a window that pops up when invoked and blocks the application, preventing any other processing or interactions from taking place until the window is closed. With the exception of the Find dialog, all the dialogs we have used so far have been modal.
A dialog is modeless if it's invoked using show() (unless we call setModal() beforehand to make it modal); it is modal if it's invoked using exec(). When we invoke modal dialogs using exec(), we typically don't need to set up any signalslot connections.
void MainWindow::goToCell() { GoToCellDialog dialog(this); if (dialog.exec()) { QString str = dialog.lineEdit->text(); spreadsheet->setCurrentCell(str.mid(1).toInt() - 1, str[0].upper().unicode() - 'A'); } }
The QDialog::exec() function returns true if the dialog is accepted, false otherwise. (Recall that when we created the Go-to-Cell dialog using Qt Designer in Chapter 2, we connected OK to accept() and Cancel to reject().) If the user chooses OK, we set the current cell to the value in the line editor; if the user chooses Cancel, exec() returns false and we do nothing.
The QTable::setCurrentCell() function expects two arguments: a row index and a column index. In the Spreadsheet application, cell A1 is cell (0, 0) and cell B27 is cell (26, 1). To obtain the row index from the QString returned by QLabel::text(), we extract the row number using QString::mid() (which returns a substring from the start position to the end of the string), convert it to an int using QString::toInt(), and subtract 1 to make it 0-based. For the column number, we subtract the numeric value of 'A' from the numeric value of the string's upper-cased first character.
Unlike Find, the Go-to-Cell dialog is created on the stack. This is a common programming pattern for modal dialogs, just as it is for context menus, since we don't need the dialog after we have used it.
We will now turn to the Sort dialog. The Sort dialog is a modal dialog that allows the user to sort the currently selected area by the columns they specify. Figure 3.14 shows an example of sorting, with column B as the primary sort key and column A as the secondary sort key (both ascending).
Figure 3.14. Sorting the spreadsheet's selected area
void MainWindow::sort() { SortDialog dialog(this); QTableSelection sel = spreadsheet->selection(); dialog.setColumnRange('A' + sel.leftCol(), 'A' + sel.rightCol()); if (dialog.exec()) { SpreadsheetCompare compare; compare.keys[0] = dialog.primaryColumnCombo->currentItem(); compare.keys[1] = dialog.secondaryColumnCombo->currentItem() - 1; compare.keys[2] = dialog.tertiaryColumnCombo->currentItem() - 1; compare.ascending[0] = (dialog.primaryOrderCombo->currentItem() == 0); compare.ascending[1] = (dialog.secondaryOrderCombo->currentItem() == 0); compare.ascending[2] = (dialog.tertiaryOrderCombo->currentItem() == 0); spreadsheet->sort(compare); } }
The code in sort() follows a similar pattern to that used for goToCell():
The compare object stores the primary, secondary, and tertiary sort keys and sort orders. (We will see the definition of the SpreadsheetCompare class in the next chapter.) The object is used by Spreadsheet::sort() to compare two rows. The keys array stores the column numbers of the keys. For example, if the selection extends from C2 to E5, column C has position 0. The ascending array stores the order associated with each key as a bool.QComboBox::currentItem() returns the index of the currently selected item, starting at 0. For the secondary and tertiary keys, we subtract one from the current item to account for the "None" item.
The sort() dialog does the job, but it is very fragile. It takes for granted that the Sort dialog is implemented in a certain way, with comboboxes and "None" items. This means that if we redesign the Sort dialog, we may also need to rewrite this code. While this approach is adequate for a dialog that is only called from one place, it opens the door to maintenance nightmares if the dialog is used in several places.
A more robust approach is to make the SortDialog class smarter by having it create a SpreadsheetCompare object itself, which can then be accessed by its caller. This simplifies MainWindow::sort() significantly:
void MainWindow::sort() { SortDialog dialog(this); QTableSelection sel = spreadsheet->selection(); dialog.setColumnRange('A' + sel.leftCol(), 'A' + sel.rightCol()); if (dialog.exec()) spreadsheet->performSort(dialog.comparisonObject()); }
This approach leads to loosely coupled components and is almost always the right choice for dialogs that will be called from more than one place.
A more radical approach is to pass a pointer to the Spreadsheet object when initializing the SortDialog object and to allow the dialog to operate directly on the Spreadsheet. This makes the SortDialog much less general, since it will only work on a certain type of widget, but it simplifies the code ever further by eliminating the SortDialog::setColumnRange() function. The MainWindow::sort() function then becomes
void MainWindow::sort() { SortDialog dialog(this); dialog.setSpreadsheet(spreadsheet); dialog.exec(); }
This approach mirrors the first: Instead of the caller needing intimate knowledge of the dialog, the dialog needs intimate knowledge of the data structures supplied by the caller. This approach may be useful where the dialog needs to apply changes live. But just as the caller code is fragile using the first approach, this third approach breaks if the data structures change.
Some developers choose just one approach to using dialogs and stick with that. This has the benefit of familiarity and simplicity since all their dialog usages follow the same pattern, but it also misses the benefits of the approaches that are not used. The decision on which approach to use should be made on a per-dialog basis.
We will round off this section with a simple About box. We could create a custom dialog like the Find or Go-to-Cell dialogs to present the "about" information, but since most About boxes are highly stylized, Qt provides a simpler solution.
void MainWindow::about() { QMessageBox::about(this, tr("About Spreadsheet"), tr("
" "
Copyright © 2003 Software Inc." "
Spreadsheet is a small application that " "demonstrates QAction, QMainWindow, " "QMenuBar, QStatusBar, " "QToolBar, and many other Qt classes.")); }
The About box is obtained by calling QMessageBox::about(), a static convenience function. The function is very similar to QMessageBox::warning(), except that it uses the parent window's icon instead of the standard "warning" icon.
Figure 3.15. About Spreadsheet
So far we have used several convenience static functions from both QMessageBox and QFileDialog. These functions create a dialog, initialize it, and call exec() on it. It is also possible, although less convenient, to create a QMessageBox or a QFileDialog widget like any other widget and explicitly call exec(), or even show(), on it.
Part I: Basic Qt
Getting Started
Creating Dialogs
Creating Main Windows
Implementing Application Functionality
Creating Custom Widgets
Part II: Intermediate Qt
Layout Management
Event Processing
2D and 3D Graphics
Drag and Drop
Input/Output
Container Classes
Databases
Networking
XML
Internationalization
Providing Online Help
Multithreading
Platform-Specific Features