Progress
Language Tutorial
for Windows


Using Dialog Boxes

The dialog box is your main tool for implementing modal interface modules. Modal interfaces require the user to complete or cancel the current operation before moving on. Modal interfaces focus the user’s attention on the current task, helping to ensure valid data and minimizing the time that Progress holds onto individual records. This behavior makes modal interfaces a natural choice for working with records in a database application.

Typically, a dialog box is the interface to some functionality that the user launches by choosing a button or menu command. This means that a dialog box is usually associated with an external procedure. The Progress AppBuilder stores these secondary interface modules with a .w file extension.

In the tutorial, you first saw the dialog box when you learned about the UPDATE statement. A dialog box overlays the main interface and blocks interaction with the main interface until the user dismisses the dialog box. In the case of the UPDATE statement, the main interface presents data for the user to view and change. Without an UPDATE statement, the user can perform an explicit action (choosing a button) to bring up the dialog box. The dialog box then gives the user the ability to change the data.

This example illustrates the concept behind a dialog box: a dialog box is an event-driven tool for implementing modes. Normally, event-driven programming strives to let users work with an application in any way that suits them. They can begin one task, start another, go back to the first, start a third—whatever makes sense to them. Event-driven programming attempts to be modeless, which means that a user can work with several parts (modes) of an application simultaneously.

In many instances, however, it is clearly desirable, or even necessary, to have a user start and complete a particular task before starting another. That’s where the dialog box comes in. When you use a dialog box, you are defining a mode—you are being modal. To go back to the UPDATE example, that technique for working with data had two clearly defined modes: viewing data and changing data. By using the dialog box, you enforced the distinction between the two modes. In event-driven programming, it’s also possible to use the same interface to view data and allow changes to the data. This technique is a modeless one.

Figure 12–2 illustrates a modeless technique.

Figure 12–2: A Modeless Interface

Figure 12–3 illustrates a modal technique.

Figure 12–3: A Modal Interface

Syntactically, the difference between a frame and a dialog box is just the VIEW-AS DIALOG-BOX option on the frame phrase. Also, while a dialog box can contain a frame family, a frame family cannot contain a dialog box. The dialog box must be the top-level parent.

The idea of a dialog box is common to all event-driven programming, and there are some widely implemented standards that go with dialog boxes. The first is the OK and Cancel buttons that you see in Figure 12–3. These buttons implement the idea that a user must dismiss a dialog box before the user can continue:

Fortunately, the Progress programming model contains these two concepts, which apply to all Progress interfaces, not just dialog boxes. The GO event function maps to the idea of “dismiss and save,” while the ENDKEY event function maps to the idea of “dismiss and discard.” Using the AUTO-GO and AUTO-ENDKEY options on the DEFINE BUTTON statement for OK and Cancel maps the GO and END-ERROR event functions to the buttons.


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095