The terms "graphical" and "GUI" don't often come up when discussing the AS/400, except by those disparaging the graphically challenged machine. Traditionally, OS/400 utilities and applications have been character-based, "green screen" programs designed to work on nonprogrammable terminals, forsaking the graphical user interface (GUI) niceties that have become commonplace with PC programs.
With the advent of client/server techniques, graphical interfaces have begun to present themselves in AS/400-based applications. These applications share database, processing, and communications functions in varying degrees between the client and the server, but they leave presentation of the application's displays entirely up to the client (the programmable PC). This approach to GUIs falls into the general philosophy of "What you do, do well."
Although PC-based architecture, languages, and techniques facilitate graphical interface development on the PC, the predominant means of creating displays for AS/400 applications remains DDS. DDS has proven itself over the last two decades to be capable of creating character-based screens, but it has generally fallen short as a tool for designing modern graphical presentations for AS/400 applications.
In recent releases of OS/400, however, IBM has enhanced DDS to include support for a few display elements commonly associated with a graphical user interface. You can now program a single-byte character-set DDS display to include the following screen components:
- Menu bars
- Pull-down menus
- Radio buttons
- Check boxes
- Scroll bars
- Continued entry fields
- Mouse interaction
This month, we look at the DDS support that lets you modernize your applications to take advantage of some of these GUI features, and I highlight the changes in V3R1.
In most cases, these GUI traits take on a "polymorphic" quality — IBM's way of saying that a given GUI element works differently on various types of workstations with differing graphic capabilities. For example, if you still have a genuine IBM 5251 terminal attached to an older workstation controller, any DDS windows you create will appear with character borders instead of the crisp, continuous lines that a brand new 3488 terminal will show when it's connected to a controller that supports the enhanced 5250 interface. For more information about specific differences between various workstation/controller and emulation combinations, see IBM's V3R1 manual, Application Display Programming (SC41-3715). For the examples in this article, I describe how the features appear on terminals with full graphical and mouse capabilities. (Note that using these features without mouse support is particularly messy — involving tab and arrow keys — so I won't go into it here.)
DDS '95 = Windows '79
Three DDS keywords let you define a record layout that overlays only part of the display — in other words, a window. You can simultaneously show up to 12 windows on a display. Each interacts with your application program as a single record format, without regard to other record formats that may be visible at the time. The three keywords are:
- WINDOW (Define a window format)
- WDWBORDER (Describe a window border)
- WDWTITLE (Assign a window title)
The WINDOW keyword defines a record format as a window and tells the system where the window goes and how big it is. WINDOW's arguments define the upper-left corner of the window (by row and column) and the number of rows and columns within it. You can also indicate whether messages should appear at the bottom of the window (*MSGLIN) or at the bottom of the physical display (*NOMSGLIN). A new argument, *RSTCSR/*NORSTCSR, gives you some flexibility in letting the user press a window's function key even when the cursor is outside the windowed record format. If you specify *NORSTCSR, the user can move the cursor outside the window and still use any valid function key; with *RSTCSR (the default), the system won't recognize the function key and will move the cursor back into the window.
The WDWBORDER keyword describes the characteristics of a window's border. The system defaults to a standard border, either a solid line if your system supports it, or a combination of colons and periods if your display doesn't support solid lines. You can override the default border with one of your own design, color, and/or attributes. Some programmers change the border to all spaces in reverse-image, which results in thick, solid lines.
Interestingly, you can use WDWBORDER to control the window borders for UIM help panels in an application. Even if your display file doesn't contain any windows, any UIM help panels you use will appear with the border attributes you specify for a nonwindow format. This feature might improve your application's appearance even if you don't use windowed formats.
A new keyword, WDWTITLE, lets you embed a title for a window within the window's top or bottom border. This feature, new with V3R1, saves valuable real estate on a display and gives the window a more integrated look on the screen. You can specify the title as a quoted string or in a program-to-system field. For most displays, you can also indicate whether the title should be *LEFT, *RIGHT, or *CENTER justified on the border.
Menu Bar Hopping
Menu bars — a row of choices listed horizontally across the top of a window — are a familiar element of any graphical user interface. When you select a choice from a menu bar (usually by clicking on it with a mouse), a pull-down menu appears, extending the more generic choices named on the menu bar. The following DDS keywords support menus:
- MNUBAR (Define a menu bar)
- MNUBARCHC (Define a choice on a menu bar)
- MNUBARDSP (Display the menu bar)
- MNUBARSEP (Describe a menu separator line)
- MNUBARSW (Assign the key to switch to the menu bar)
- MNUCNL (Assign a cancel key for a menu)
- PULLDOWN (Define a pull-down menu)
- SNGCHCFLD (Define a single-choice field)
- CHOICE (Describe a choice)
- CHCACCELL (Provide a keyboard alternative to make the same choice)
The three "key" keywords involved in creating a menu bar are MNUBAR, MNUBARCHC, and MNUBARDSP. To define a record as a menu bar, you include the MNUBAR keyword in its record format. The menu bar record format must also include a numeric field that communicates the user's choice to the application program. This field must include one or more MNUBARCHC keywords, which you use to specify which pull-down menu you want to appear for each choice on the menu bar. MNUBARDSP simply tells the system to display this menu bar, much like the SFLDSP keyword displays a subfile.
Each pull-down menu is a separate record format, which includes the PULLDOWN keyword. A pull-down menu's DDS code consists of a numeric field for which you include the SNGCHCFLD keyword, to indicate that this field will contain a number corresponding to the user's choice. Use the CHOICE keyword to list each choice for the pull-down menu.
Bars, Buttons, and Boxes
In addition to windows and menu bars, DDS supports several other miscellaneous graphical entities, including vertical scroll bars, radio buttons, and check boxes.
In early DDS days on the S/38, you had to "know the code" to determine whether a subfile still had more data to show you. A solitary "+" at the lower right-hand corner of the subfile display indicated that you could scroll to see additional information. The "+" disappeared when the subfile reached the end. AS/400 subfiles improved on the cryptic symbol with the now familiar "More..." and "Bottom." With graphical DDS support, you can now use the vertical scroll bar common to many PC GUI applications.
By specifying SFLEND(*SCRBAR *MORE) in the DDS definition for a subfile control record, you tell a graphically enabled workstation to display a fully functional scroll bar to the right of the subfile; if you're not using a graphical display, "More..." and "Bottom" will take over. Figure 5 shows a scroll bar, which responds to the mouse just as it would in a PC application. Clicking the top or bottom scroll button moves the subfile in that direction; you can also drag the positioning bar (between the top and bottom buttons) to a specific location in the subfile.
As with most DDS functions, some restrictions apply. The scroll bar takes up the last four columns of the display, so those columns are unavailable to show subfile fields. Also, fields cannot wrap beyond one line of the subfile.
Note that, if your technique is to load one subfile page at a time (instead of the entire subfile), your scroll bar will usually depict a more accurate representation of the subfile position if you specify SFLSIZ as one record larger than the SFLPAG setting. Alternatively, you could use the new SLFSIZ support that lets you dynamically specify the size of the subfile using a program-to-system field (data type S, length 5). By including in this field the number of records your application will add to the subfile, you can ensure that the scroll bar will accurately reflect the subfile position.
Radio buttons and check boxes are the primary graphical selection indicators DDS supports. They appear on-screen in front of choice fields. Radio buttons are round buttons that indicate the user can make only a single choice among a list; when one choice is selected, all the other choices in the group are deselected. Check boxes, on the other hand, let the user select more than one choice in a group. To define a field as a single-choice field (with radio buttons), use the SNGCHCFLD keyword. The MLTCHCFLD keyword identifies a multiple-choice field (with check boxes). Multiple choice fields usually also include the CHCCTL keyword to associate each choice with an additional field that your program can process. For more information, see IBM's DDS Reference (SC41-3712). Figure 6 shows how to code radio buttons and check boxes; the code produces the screen in Figure 7.
Several new keywords let you use subfiles as selection lists so users can click on one or more items for the program to process. You can define a subfile as a single-choice or a multiple-choice selection list to let the user select one or several items. The main difference between a choice field and a selection list is that the selection list is scrollable (using the page keys or the scroll bar). You can also easily vary the number of selections available when you define a selection list, whereas the number of choices in a choice field is usually set at the time you define the display. DDS supports selection lists using these new keywords:
- SFLCHCCTL (Subfile choice control)
- SFLMLTCHC (Subfile multiple-choice selection list)
- SFLSNGCHC (Subfile single-choice selection list)
Creating selection lists is more involved than this month's overview will let us discuss; for more information about this potentially helpful tool, see the DDS Reference.
Figures 6 and 7 also illustrate the use of a new feature, push-button fields. A push button lets the user start an action. The field appears on screen as one or a group of push buttons. To define a push- button field, use the PSHBTNFLD and PSHBTNCHC keywords. In the example in Figures 6 and 7, I listed "Enter" and "Cancel" as valid buttons and indicated that the display should treat the Cancel button just as it would treat the F12 function key.
Big Steps, Little Steps
As we've seen, the venerable DDS has taken some giant strides toward supporting some graphical components. Is it worth your trouble to learn to use this support to modernize your applications? Probably. The effort is minimal, and the results are a noticeable improvement. If your shop is still 5250-centric, your users will appreciate the productivity enhancements that a graphical interface will afford them.
But be assured that the trend for application development is moving away from DDS screens and toward PC-based GUIs using client/server technology. When you compare a graphically enhanced DDS screen with almost any PC application, the green screen still falls short. So go ahead and beautify your green screens, but keep your eye on the future, too. Be sure to explore visual programming techniques, PC languages, and client/server architectures to keep up with where the AS/400 is going.
Bryan Meyers, CCP, is director of information services for KOA Kampgrounds of America and a technical editor for NEWS/400. You can contact Bryan by fax at (406) 254- 7414, or on the Internet (email@example.com).