Designing Dialogs
A dialog is a unit of work within an CA ADS application that enables interaction with the user. Because dialogs are the basic building blocks of an CA ADS application, it is important that they be well-designed. This section discusses characteristics and design features of dialogs that merit the attention of application developers.
idmscu
A dialog is a unit of work within an CA ADS application that enables interaction with the user. Because dialogs are the basic building blocks of an CA ADS application, it is important that they be well-designed. This section discusses characteristics and design features of dialogs that merit the attention of application developers.
Contents
Dialog Characteristics
The characteristics of a dialog determine its role within the application; each dialog has an implicit level and status, and can pass and receive control of the processing. The significance of the dialog level and status and the manner in which control is passed are discussed the following sections.
Dialog Level
Developer's Role
The level of a dialog refers to its position within the application structure. The application developer can pass processing control to a dialog at the next lower level, the same level, the next higher level, or the top level of the application structure.
The meaning of TOP changes whenever a LINK command is executed. The dialog issuing LINK becomes the current TOP.
Aspects Influenced
At runtime, the dialog level affects the following aspects of an application:
- Availability of data-- When combined with the manner in which processing control is received, the level of a dialog governs the data passed in the record buffer blocks and the currencies that are established, saved, stored, or released.
- Use of system resources-- The runtime system maintains record buffer blocks, database currency blocks, and variable dialog blocks for dialogs at each level. There is a direct correlation between the number of dialog levels in an application and the size of the storage pool that is needed.
- Performance-- The number of dialog levels can affect the performance of an application. For example, performance times are affected if a frequently accessed dialog is located three or four levels down in an application structure.
An application can be composed of any number of dialog levels, but the most efficient application uses many levels only when absolutely necessary.
The top-level dialog must be a
mainline
dialog and must be defined as such by the application developer. A mainline dialog is the entry point to the application. An application can have more than one mainline dialog; entry points can also be established at a lower level in the application structure. In addition to defining a task code for the top-level dialog, the developer can identify an alternative entry point by using the Task Definition screen to associate a task code with a lower-level function.Dialog Status
Dialog Types
A dialog can have an
operative
or a nonoperative
status within the application thread. A dialog becomes operative when it receives control and begins executing; at a given level, only one dialog can be operative at a time.When control passes to a dialog at another level, the issuing dialog can remain operative or can become nonoperative, depending upon the level of the next dialog. For example, when control is passed with the LINK command, the issuing dialog remains operative; when control is passed with the TRANSFER command, the issuing dialog becomes nonoperative.
As long as a dialog is operative, all data that it has acquired is retained. When a dialog becomes nonoperative, its data is released. See the table, later in this section, that summarizes the way in which a dialog's status is affected by the successful execution of a control command.
Sequence of Dialog Execution
Within the application structure, only one dialog executes at a time. The sequence of dialog execution within an application structure is called the
application thread
. The response of the user determines the dialogs that constitute a given application thread.One dialog can exist in several places within the application structure and be part of the same or different application threads. A dialog can execute more than once within the application thread whether or not it remains operative.
Dialog Control
Passing control to another dialog
A dialog passes control to another dialog based on the execution of a control command and/or the user's selection of processing. The dialog that receives control can be a different dialog, a copy of the executing dialog, or all or part of the executing dialog itself.
The application developer can use specific control commands to perform the following operations:
- Pass processing control from one dialog to another dialog or to a user program.
- Display a dialog's map.
- Terminate an existing dialog or application.
- Exit CA ADS.
- Pass processing control to specified points within a dialog and reinitialize the record buffers associated with a dialog.
Most of the control commands used are available to all applications. When designing dialogs that will become part of an application that is compiled in an ADSA session, the developer can also use the EXECUTE NEXT FUNCTION command.
For a discussion of the commands that direct the flow of control within an application, see Application Concepts. This section also contains a diagram and discussion of how the runtime system determines the order in which the functions of an application are executed.