PreviousThe Graphical User Interface Creating a Data Definition and ScreensetNext

Chapter 2: Introduction to Dialog System

The previous chapter described the advantages of using a graphical user interface (GUI). This chapter introduces you to the basic concepts which you need in order to use Dialog System when creating GUIs for your COBOL applications. These include:

2.1 Benefits of Using Dialog System

Dialog System offers you the following benefits:

2.2 Overview of Dialog System's Capabilities

Dialog System enables you to design and edit windows and dialog boxes for display on a Windows system and to pass data between this interface and your application program. The two aspects of Dialog System which enable these functions are:

This section describes in outline what the definition software is and how it enables you to create a user interface, covering:

2.2.1 Designing Your Interface

The first step when you develop a Dialog System application with a GUI is to design a data model. The model defines the data which is to be both captured by the user interface and provided by the application to be presented to the user.

This data model provides the basic data items that must be passed to the calling program. You must also decide on any validation criteria for these items.

Some of the desirable features you should consider for your user interface are:

User controlled Users are in control of the interface. They determine the course of action of the application.
Easy to use The user can move easily and naturally around a window and between windows. The information displayed is well organized, easy to read, and appears uncluttered.
Consistent The user interface is consistent internally as well as across applications. For example, the Exit choice on a window is always the last option in the File menu. Another example is that any delete action requiresadditional confirmation.
Helpful Users are given clear, informative feedback on where they are in the system, what actions they have taken, and what action they should take next. It is better for the user to select an item from a list rather than enter the item in a data entry field.
Forgiving User actions are easily reversed. Error messages explain what the error was, why the error occurred, and possible corrections to the error.
Efficient System response times are kept as short as possible.
Complete If a user has a list of choices, all choices are valid and available to the user.
Logical Choices on a menu are logically organized, with the most frequently chosen item listed first or with the items listed alphabetically.

You also need to consider how the user interacts with the data – the user interface.

The user interface you build can take many forms, ranging from simple menu selection and data entry fields to fully developed windows complete with menu bars, radio buttons and other controls.

The level of sophistication of the interface you choose depends on many factors including:

In all cases:

The basic visual elements which you define for your user interface are called objects. These objects, such as windows, dialog boxes and push buttons, appear on an area bounded by the screen, in which everything else appears.

In Dialog System, there are two main categories of objects: Window Objects

These are the most basic (and often the most important) objects. They can be primary or secondary and are very similar to dialog boxes and message boxes. The appearance of windows and dialog boxes is the same at both definition and run time.

You can define window objects at any time and place them anywhere on the desktop. You can move these objects by dragging the title bar and you can size windows using their sizable borders. When selected, you see them surrounded by a colored, shaded border.

For further information, see the chapter Window Objects. Control Objects

All other objects are control objects. These are the objects that appear in the windows and include entry fields, push buttons, radio buttons, check boxes and list boxes.

You can define other control objects which extend Dialog System's default range of objects. When you define such a control object, Dialog System can generate a tailored controlling program for the control.

The two types of additional controls that you can define are:

Both of these types of controls are described in the chapters Control Objects and Programming Your Own Controls. Object Properties

Every window object and control object has properties, for example, background color. You can change these properties to specify the object's appearance and behavior.

You can use the default properties of an object by selecting Include on the Options menu and selecting Auto properties. In this case Dialog System uses the default property values for that object and does not display the Properties dialog box. You can change the properties of the object using the Properties dialog box by selecting Properties on the Edit menu or double-clicking on the object.

If Auto properties is not selected, Dialog System immediately displays the Properties dialog box for an object, so you can set the properties. If you click Cancel in this dialog box at this stage, the object is removed. If you click OK, the object is defined using the properties displayed in the dialog box.

If you define a message box, bitmap, ActiveX or User control, the Properties dialog box is always displayed, regardless of the setting of Auto properties. Working with Objects

To work with an object, you must make it the current object. When you define an object initially, Dialog System automatically makes it the current object. Naming Objects

A common property of all objects is a name. For some objects, it is required, and for some it is optional. If you give an object a name, that name must be unique.

A good programming practice is to set up a naming convention for the variables in your COBOL program. A consistent naming convention enables you or another developer to understand your application more easily.

We also recommend that you establish a similar naming convention for the objects in your user interface.

One fairly simple naming convention consists of the concatenation of:


where the concatenated parts are:

windowname The name of the window the object is located on, or if the object is itself a window, just the window name.
objectinfo Some identifying information about the object. The information should uniquely identify the object on this window, for example, the text that appears on a push button.
objecttype An abbreviated name that identifies the type of object. For example, you could use win for window, pb for push button, db for dialog box and so on.

Using this convention, a window used to gather information about a new employee could be named NEW-EMPLOYEE-WIN. A push button on the same window could be named NEW-EMPLOYEE-OK-PB. An entry field on the window that is used to input salary information could be named NEW-EMPLOYEE-SALARY-EF.

2.2.2 Using Dialog

A user interface is more than just a graphical display. A complete specification also describes how the user and computer interact and how the user interface software interacts with the application software.

Once you have defined the appearance of the display, you must define this run-time interaction between the user and the machine. This interaction is called dialog. Dialog consists of events and functions. When an event occurs, the functions associated with the event are executed. Events can be caused by a key on the keyboard being pressed, or a menu choice or an object being selected.

For example, a Dialog System event such as BUTTON-SELECTED occurs when a user selects a push button (with the mouse or keyboard). If the button selected is Enter, the function associated with it might be CREATE-WINDOW, to create a new window for the user to enter more information.

Dialog System lets you create or customize the dialog between the user and the display objects.

For more information on dialog statements, see the chapter Using Dialog and the topic Dialog System Overview in the Help. Events

An event signifies some change in the user interface: events happen to objects such as windows, bitmaps, list boxes and buttons. There are many different operations which can trigger an event, such as:

Intrinsically, all events are the same. However, for convenience, they can be divided into three types:

When an event occurs, Dialog System searches first in the relevant control dialog, then the relevant window dialog, then the global dialog. Defining an event is part of the process of creating a Dialog Definition. Events are defined by associating Functions with them. Functions

Functions are instructions to Dialog System to do something. They are associated with events and operate when:

Dialog System has a comprehensive set of functions. Some are specific to moving around screensets, for example SET-FOCUS or INVOKE-MESSAGE-BOX. Some are similar to other programming language instructions, for example MOVE data from one data item to another.

You can find a complete description of the functions in the topic Dialog Statements: Functions in the Help. Procedures

A procedure is an arbitrary name with a set of functions listed under it; in other words, a subroutine. You can think of a procedure as being like an event.

2.2.3 Using the Data Block and Screenset

Dialog System creates a file, called a screenset, which holds the definitions of all the windows and dialog boxes as you create them for your interface. It is called This includes any on-screen objects which you may need in your interface, for example, entry fields.

When you run your interface, objects such as entry fields contain data which you need to pass between the interface and your application program. You do this by associating your on-screen objects with data items defined in your application program. These data items are called master fields in Dialog System. You make the association by selecting the appropriate master field when editing the control's properties.

These data definitions are held in the screenset file and form the Data Block. When the generated program calls Dialog System's run-time support module, dsgrun, it passes the Data Block as a parameter.

The screenset file holds:

2.3 Steps for Creating an Application Using Dialog System

To start Dialog System:

The steps that you need to follow to create an application with Dialog System are:

  1. Define data and validations.

    See the section Steps for Creating a Data Definition in the chapter Creating a Data Definition and Screenset and the topic Data Definition and Validation in the Help.

  2. Define windows, dialog boxes and message boxes.

    See the chapters Window Objects and Control Objects.

  3. Define control objects (such as entry fields, text fields and radio buttons) and place them on the windows and dialog boxes.

    See the chapters Window Objects, Control Objects and Using Dialog.

  4. Save your screenset.

    It is a good idea to save a screenset whenever you have finished a stage in the definition process. The first time you save a screenset, use Save As. Dialog System displays a dialog box for you to enter the filename and directory you want to save under.

    After saving the sample screenset once, you can use Save whenever you want to save the screenset. If you want to try out different versions of the screenset, use Save As with a new name to create another version.

  5. Test your screenset.

    Examine the behavior of the screenset using the Screenset Animator. See the section Screenset Animator in the Help.

  6. Define dialog.

    Define object dialog that controls the behavior of objects.

  7. Test the screenset again.

    See the section Screenset Animator in the Help.

  8. Change the screenset as required.

    Go back to earlier stages of this process.

  9. Generate the COBOL copyfile from the screenset.

    See the section Steps for Creating a Data Definition in the chapter Creating a Data Definition and Screenset.

  10. Write the COBOL application program with the necessary calls to the Dialog System run-time system.

    See the chapter Using the Screenset.

  11. Animate and test the COBOL program.

    See the topic Debugging in the Help.

  12. Package your application.

    See the topic Compiling and Linking in the Help.

You do not need to follow this order strictly. You can define objects before you define data if you wish, but you cannot define object dialog until you have defined an object to which you can attach the dialog.

Copyright © 1998 Micro Focus Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.
PreviousThe Graphical User Interface Creating a Data Definition and ScreensetNext