All dialogs share some basic properties. They are window-owning controls; virtually all dialog classes are ultimately derived from CCoeControl , as described in Chapter 5. A dialog framework manages many aspects of their behavior, including layout, drawing and the management of the user interaction with their component controls. Typically, most dialogs of any complexity are fully defined in a resource file and, after dynamic instantiation; their construction is completed by having the dialog framework load the definition from the resource file. The layout and positioning of all the elements of the dialog is usually automatic ”the developer can influence the process, as described later. Full dynamic construction is possible for very simple dialogs.
Dialogs can be modal or modeless , as well as waiting or nonwaiting . They have a number of lines arranged vertically, each containing one or more controls.
A modal dialog prevents you from interacting with other parts of the application's UI until you dismiss it, while a modeless dialog does allow you to interact with other parts of the application's UI while it is active.
A nonwaiting dialog allows the application to continue processing in the background, whereas a waiting dialog prevents an application from doing any further processing until the dialog is dismissed.
Series 60 dialogs are modal and nonwaiting by default. Modeless dialogs are rarely used in Series 60, as any dialog shown will generally have input focus until it is dismissed. Dialogs used as the main view in a Dialog-Based Application Architecture are the main exception ”see Chapter 4 for further details.