Modeless Dialogs

In the Microsoft Foundation Class (MFC) Library version 6.0, modal and modeless dialogs share the same base class, CDialog, and they both use a dialog resource that you can build with the dialog editor. If you're using a modeless dialog with a view, you'll need to know some specialized programming techniques.

Creating Modeless Dialogs

For modal dialogs, you've already learned that you construct a dialog object using a CDialog constructor that takes a resource template ID as a parameter, and then you display the modal dialog window by calling the DoModal member function. The window ceases to exist as soon as DoModal returns. Thus, you can construct a modal dialog object on the stack, knowing that the dialog window has been destroyed by the time the C++ dialog object goes out of scope.

Modeless dialogs are more complicated. You start by invoking the CDialog default constructor to construct the dialog object, but then to create the dialog window you need to call the CDialog::Create member function instead of DoModal. Create takes the resource ID as a parameter and returns immediately with the dialog window still on the screen. You must worry about exactly when to construct the dialog object, when to create the dialog window, when to destroy the dialog, and when to process user-entered data.

Here's a summary of the differences between creating a modal dialog and a modeless dialog.

	Modal Dialog	Modeless Dialog
Constructor used	Constructor with resource ID param	Default constructor (no params)
Function used to create window	DoModal	Create with resource ID param

User-Defined Messages

Suppose you want the modeless dialog window to be destroyed when the user clicks the dialog's OK button. This presents a problem. How does the view know that the user has clicked the OK button? The dialog could call a view class member function directly, but that would "marry" the dialog to a particular view class. A better solution is for the dialog to send the view a user-defined message as the result of a call to the OK button message-handling function. When the view gets the message, it can destroy the dialog window (but not the object). This sets the stage for the creation of a new dialog.

You have two options for sending Windows messages: the CWnd::SendMessage function or the PostMessage function. The former causes an immediate call to the message-handling function, and the latter posts a message in the Windows message queue. Because there's a slight delay with the PostMessage option, it's reasonable to expect that the handler function has returned by the time the view gets the message.

Dialog Ownership

Now suppose you've accepted the dialog default pop-up style, which means that the dialog isn't confined to the view's client area. As far as Windows is concerned, the dialog's "owner" is the application's main frame window (introduced in Chapter 13), not the view. You need to know the dialog's view to send the view a message. Therefore, your dialog class must track its own view through a data member that the constructor sets. The CDialog constructor's pParent parameter doesn't have any effect here, so don't bother using it.

A Modeless Dialog Example—EX07A

We could convert the Chapter 6 monster dialog to a modeless dialog, but starting from scratch with a simpler dialog is easier. Example EX07A uses a dialog with one edit control, an OK button, and a Cancel button. As in the Chapter 6 example, pressing the left mouse button while the mouse cursor is inside the view window brings up the dialog, but now we have the option of destroying it in response to another event—pressing the right mouse button when the mouse cursor is inside the view window. We'll allow only one open dialog at a time, so we must be sure that a second left button press doesn't bring up a duplicate dialog.

To summarize the upcoming steps, the EX07A view class has a single associated dialog object that is constructed on the heap when the view is constructed. The dialog window is created and destroyed in response to user actions, but the dialog object is not destroyed until the application terminates.

Here are the steps to create the EX07A example:

1. Run AppWizard to produce \vcpp32\ex07a\ex07a. Accept all the defaults but two: select Single Document and deselect Printing And Print Preview. The options and the default class names are shown here.

2. Use the dialog editor to create a dialog resource. Choose Resource from Visual C++'s Insert menu, and then select Dialog. The dialog editor assigns the ID IDD_DIALOG1 to the new dialog. Change the dialog caption to Modeless Dialog. Accept the default OK and Cancel buttons with IDs IDOK and IDCANCEL, and then add a static text control and an edit control with the default ID IDC_EDIT1. Change the static text control's caption to Edit 1. Here is the completed dialog.

Be sure to select the dialog's Visible property.

3. Use ClassWizard to create the CEx07aDialog class. Choose ClassWizard from Microsoft Visual C++'s View menu. Fill in the New Class dialog as shown here, and then click the OK button.

Add the message-handling functions shown next. To add a message-handling function, click on an object ID, click on a message, and then click the Add Function button. The Add Member Function dialog box appears. Edit the function name if necessary, and click the OK button.

Object ID	Message	Member Function
IDCANCEL	BN_CLICKED	OnCancel
IDOK	BN_CLICKED	OnOK

4. Add a variable to the CEx07aDialog class. While in ClassWizard, click on the Member Variables tab, choose the IDC_EDIT1 control, and then click the Add Variable button to add the CString variable m_strEdit1.

5. Edit ex07aDialog.h to add a view pointer and function prototypes. Type in the following boldface code in the CEx07aDialog class declaration:

   private:     CView* m_pView; 

   Also, add the function prototypes as follows:

   public:     CEx07aDialog(CView* pView);     BOOL Create(); 

Using the CView class rather than the CEx07aView class allows the dialog class to be used with any view class.