Subclassing QDialog

Our first example is a Find dialog written entirely in C++. We will implement the dialog as a class in its own right. By doing so, we make it an independent, self-contained component, with its own signals and slots.

Figure 2.1. Find dialog on Linux (KDE)

The source code is spread across two files: finddialog.h and finddialog.cpp. We will start with finddialog.h.

1 #ifndef FINDDIALOG_H 2 #define FINDDIALOG_H 3 #include 4 class QCheckBox; 5 class QLabel; 6 class QLineEdit; 7 class QPushButton;

Lines 1 and 2 (and 27) prevent the header file from multiple inclusions.

Line 3 includes the definition of QDialog, the base class for dialogs in Qt. QDialog inherits QWidget.

Lines 4 to 7 are forward declarations of the Qt classes that we will use to implement the dialog. A forward declaration tells the C++ compiler that a class exists, without giving all the detail that a class definition (usually located in a header file of its own) provides. We will say more about this shortly.

We then define FindDialog as a subclass of QDialog:

8 class FindDialog : public QDialog 9 { 10 Q_OBJECT 11 public: 12 FindDialog(QWidget *parent = 0, const char *name = 0);

The Q_OBJECT macro at the beginning of the class definition is necessary for all classes that define signals or slots.

The FindDialog constructor is typical of Qt widget classes. The parent parameter specifies the parent widget, and the name parameter gives the widget a name. The name is optional; it is primarily used for debugging and testing.

13 signals: 14 void findNext(const QString &str, bool caseSensitive); 15 void findPrev(const QString &str, bool caseSensitive);

The signals section declares two signals that the dialog emits when the user clicks the Find button. If the Search backward option is enabled, the dialog emits findPrev(); otherwise, it emits findNext().

The signals keyword is actually a macro. The C++ preprocessor converts it into standard C++ before the compiler sees it.

16 private slots: 17 void findClicked(); 18 void enableFindButton(const QString &text); 19 private: 20 QLabel *label; 21 QLineEdit *lineEdit; 22 QCheckBox *caseCheckBox; 23 QCheckBox *backwardCheckBox; 24 QPushButton *findButton; 25 QPushButton *closeButton; 26 }; 27 #endif

In the class's private section, we declare two slots. To implement the slots, we will need to access most of the dialog's child widgets, so we keep pointers to them as well. The slots keyword is, like signals, a macro that expands into a construct that the C++ compiler can digest.

Since all the variables are pointers and we don't use them in the header file, the compiler doesn't need the full class definitions; forward declarations are sufficient. We could have included the relevant header files (, , etc.) instead, but using forward declarations when it is possible makes compiling somewhat faster.

We will now look at finddialog.cpp, which contains the implementation of the FindDialog class:

1 #include 2 #include 3 #include 4 #include 5 #include 6 #include "finddialog.h"

First, we include the header files for all the Qt classes we use, in addition to finddialog.h. For most Qt classes, the header file is a lower-case version of the class name with a .h extension.

7 FindDialog::FindDialog(QWidget *parent, const char *name) 8 : QDialog(parent, name) 9 { 10 setCaption(tr("Find")); 11 label = new QLabel(tr("Find &what:"), this); 12 lineEdit = new QLineEdit(this); 13 label->setBuddy(lineEdit); 14 caseCheckBox = new QCheckBox(tr("Match &case"), this); 15 backwardCheckBox = new QCheckBox(tr("Search &backward"), this); 16 findButton = new QPushButton(tr("&Find"), this); 17 findButton->setDefault(true); 18 findButton->setEnabled(false); 19 closeButton = new QPushButton(tr("Close"), this);

On line 8, we pass on the parent and name parameters to the base class constructor.

On line 10, we set the window's caption to "Find". The tr() function around the string marks it for translation to other languages. It is declared in QObject and every subclass that contains the Q_OBJECT macro. It's a good habit to surround every user-visible string with a tr(), even if you don't have immediate plans for translating your applications to other languages. Translating Qt applications is covered in Chapter 15.

Then we create the child widgets. We use ampersands ('&') to indicate accelerator keys. For example, line 16 creates a Find button, which the user can activate by pressing Alt+F. Ampersands can also be used to control focus: On line 11 we create a label with an accelerator key (Alt+W), and on line 13 we set the label's buddy to be the line editor. A buddy is a widget that accepts the focus when the label's accelerator key is pressed. So when the user presses Alt+W (the label's accelerator), the focus goes to the line editor (the buddy).

On line 17, we make the Find button the dialog's default button by calling setDefault(true).[*] The default button is the button that is pressed when the user hits Enter. On line 18, we disable the Find button. When a widget is disabled, it is usually shown grayed out and will not interact with the user.

[*] Qt provides TRUE and FALSE for all platforms and uses them throughout as synonyms for the standard true and false. Nevertheless, there is no reason to use the upper-case versions in your own code unless you need to use an old compiler that doesn't support true and false.

20 connect(lineEdit, SIGNAL(textChanged(const QString &)), 21 this, SLOT(enableFindButton(const QString &))); 22 connect(findButton, SIGNAL(clicked()), 23 this, SLOT(findClicked())); 24 connect(closeButton, SIGNAL(clicked()), 25 this, SLOT(close()));

The private slot enableFindButton(const QString &) is called whenever the text in the line editor changes. The private slot findClicked() is called when the user clicks the Find button. The dialog closes itself when the user clicks Close. The close() slot is inherited from QWidget, and its default behavior is to hide the widget. We will look at the code for the enableFindButton() and findClicked() slots later on.

Since QObject is one of FindDialog's ancestors, we can omit the QObject:: prefix in front of the connect() calls.

26 QHBoxLayout *topLeftLayout = new QHBoxLayout; 27 topLeftLayout->addWidget(label); 28 topLeftLayout->addWidget(lineEdit); 29 QVBoxLayout *leftLayout = new QVBoxLayout; 30 leftLayout->addLayout(topLeftLayout); 31 leftLayout->addWidget(caseCheckBox); 32 leftLayout->addWidget(backwardCheckBox); 33 QVBoxLayout *rightLayout = new QVBoxLayout; 34 rightLayout->addWidget(findButton); 35 rightLayout->addWidget(closeButton); 36 rightLayout->addStretch(1); 37 QHBoxLayout *mainLayout = new QHBoxLayout(this); 38 mainLayout->setMargin(11); 39 mainLayout->setSpacing(6); 40 mainLayout->addLayout(leftLayout); 41 mainLayout->addLayout(rightLayout); 42 }

Finally, we lay out the child widgets using layout managers. A layout manager is an object that manages the size and position of widgets. Qt provides three layout managers: QHBoxLayout lays out widgets horizontally from left to right (right to left for some cultures), QVBoxLayout lays out widgets vertically from top to bottom, and QGridLayout lays out widgets in a grid.

Layouts can contain both widgets and other layouts. By nesting QHBoxLayouts, QVBoxLayouts, and QGridLayouts in various combinations, it is possible to build very sophisticated dialogs.

For the Find dialog, we use two QHBoxLayouts and two QVBoxLayouts, as shown in Figure 2.2. The outer layout is the main layout; it is constructed with the FindDialog object (this) as its parent and is responsible for the dialog's entire area. The other three layouts are sub-layouts. The little "spring" at the bottom right of Figure 2.2 is a spacer item (or "stretch"). It uses up the empty space below the Find and Close buttons, ensuring that these buttons occupy the top of their layout.

Figure 2.2. The Find dialog's layouts

One subtle aspect of the layout manager classes is that they are not widgets. Instead, they inherit QLayout, which in turn inherits QObject. In the figure, widgets are represented by solid outlines and layouts are represented by dashed outlines to highlight the difference between them. In a running application, layouts are invisible.

Although layout managers are not widgets, they can have a parent (and children). The meaning of "parent" is slightly different for layouts than for widgets. If a layout is constructed with a widget as its parent (as we did for mainLayout), the layout automatically installs itself on the widget. If a layout is constructed with no parent (as we did for topLeftLayout, leftLayout, and rightLayout), the layout must be inserted into another layout using addLayout().

Qt's parentchild mechanism is implemented in QObject, the base class of both QWidget and QLayout. When we create an object (a widget, layout, or other kind) with a parent, the parent adds the object to the list of its children. When the parent is deleted, it walks through its list of children and deletes each child. The children themselves then delete all of their children, and so on recursively until none remain.

The parentchild mechanism simplifies memory management a lot, reducing the risk of memory leaks. The only objects we must delete explicitly are the objects we create with new and that have no parent. And if we delete a child object before its parent, Qt will automatically remove that object from the parent's list of children.

For widgets, the parent has an additional meaning: Child widgets are shown within the parent's area. When we delete the parent widget, not only does the child vanish from memory, it also vanishes from the screen.

When we insert a layout into another using addLayout(), the inner layout is automatically made a child of the outer layout, to simplify memory management. In contrast, when we insert a widget into a layout using addWidget(), the widget doesn't change parent.

Figure 2.3 shows the parentage of the widgets and layouts. The parentage can easily be deduced from the FindDialog constructor code by looking at the lines that contain a new or an addLayout() call. The important thing to remember is that the layout managers are not parents of the widgets they manage.

Figure 2.3. The Find dialog's parentchild relationships

In addition to the layout managers, Qt provides some layout widgets: QHBox (which we used in Chapter 1), QVBox, and QGrid. These classes serve both as parents and as layout managers for their child widgets. The layout widgets are more convenient to use than layout managers for small examples, but they are less flexible and require more resources.

This completes the review of FindDialog's constructor. Since we used new to create the dialog's widgets and layouts, it would seem that we need to write a destructor that calls delete on each of the widgets and layouts we created. But this isn't necessary, since Qt automatically deletes child objects when the parent is destroyed, and the objects we allocated with new are all descendants of the FindDialog.

Now we will look at the dialog's slots:

43 void FindDialog::findClicked() 44 { 45 QString text = lineEdit->text(); 46 bool caseSensitive = caseCheckBox->isOn(); 47 if (backwardCheckBox->isOn()) 48 emit findPrev(text, caseSensitive); 49 else 50 emit findNext(text, caseSensitive); 51 } 52 void FindDialog::enableFindButton(const QString &text) 53 { 54 findButton->setEnabled(!text.isEmpty()); 55 }

The findClicked() slot is called when the user clicks the Find button. It emits the findPrev() or the findNext() signal, depending on the Search backward option. The emit keyword is specific to Qt; like other Qt extensions, it is converted into standard C++ by the C++ preprocessor.

The enableFindButton() slot is called whenever the user changes the text in the line editor. It enables the button if there is some text in the editor, and disables it otherwise.

These two slots complete the dialog. We can now create a main.cpp file to test our FindDialog widget:

1 #include 2 #include "finddialog.h" 3 int main(int argc, char *argv[]) 4 { 5 QApplication app(argc, argv); 6 FindDialog *dialog = new FindDialog; 7 app.setMainWidget(dialog); 8 dialog->show(); 9 return app.exec(); 10 }

To compile the program, run qmake as usual. Since the FindDialog class definition contains the Q_OBJECT macro, the makefile generated by qmake will include special rules to run moc, Qt's meta-object compiler.

For moc to work correctly, we must put the class definition in a header file, separate from the implementation file. The code generated by moc includes this header file and adds some magic of its own.

Classes that use the Q_OBJECT macro must have moc run on them. This isn't a problem because qmake automatically adds the necessary rules to the makefile. But if you forget to regenerate your makefile using qmake and moc isn't run, the linker will complain that some functions are declared but not implemented. The messages can be fairly obscure. GCC produces warnings like this one:

finddialog.o(.text+0x28): undefined reference to 'FindDialog::QPaintDevice virtual table'

Visual C++'s output starts like this:

finddialog.obj : error LNK2001: unresolved external symbol "public:~virtual bool __thiscall FindDialog::qt_property(int, int,class QVariant *)"

If this ever happens to you, run qmake again to update the makefile, then rebuild the application.

Now run the program. Verify that the accelerator keys Alt+W, Alt+C, Alt+B, and Alt+F trigger the correct behavior. Press Tab to navigate through the widgets with the keyboard. The default tab order is the order in which the widgets were created. This can be changed by calling QWidget::setTabOrder().

Providing a sensible tab order and keyboard accelerators ensures that users who don't want to (or cannot) use a mouse are able to make full use of the application. Full keyboard control is also appreciated by fast typists.

In Chapter 3, we will use the Find dialog inside a real application, and we will connect the findPrev() and findNext() signals to some slots.