RAD Development with DrDialog

By Douglas Clark

Every once in awhile a pivotal product come along which changes the face of computing and creates a whole new category of applications.Visual Basic was one of those products for Windows. It allowed non-programmers, or at least non C programmers, to rapidly create applications with graphical user interfaces (GUI) by visually placing and sizing GUI components. Visual Basic spawned a category of products called RAD - rapid application development - that were aimed at rapid easy development of GUI applications.

OS/2 was not left behind the RAD revolution. But where Basic was the main language for rapid GUI development in Windows, Rexx was the RAD language in OS2. Many RAD Rexx packages were released for OS/2: VX-REXX, VisPro/Rexx, GpfRexx to name three. One of the earliest RAD packages for OS/2 was an IBM employee written product called DrDialog. DrDialog was originally released as part of the Developer Connection package of tools, but is now available from Hobbes, OS2BBS, LEO, and a number of other sources.

DrDialog ended up being different from the other packages in that it was designed with a very narrow focus, while the other packages were big products that bundled lots of other features such as database access, database specific controls, and reports with the basic GUI building functions. DrDialog was designed to provide the resources for building GUI Rexx applications and nothing more. And although the product is now 8 years old, it is still very powerful and useful, thanks to its narrow focus and the stability of OS/2's Presentation Manager API.

Installation

Installing DrDialog is straightforward:

1. create the directory on your hard drive where DrDialog will live
2. unzip the package into the directory
3. run the INSTALL.CMD file.

The INSTALL.CMD program creates the Workplace shell objects. If this is the first time you have installed DrDialog you will be prompted for where to place the profile (*.INI) information - usually the default of the install directory will work fine.

Visual Development

GUI applications consist of one or more windows containing the graphical components the user interacts with, such as scroll bars, push buttons etc. These components are called "controls" and in OS/2 are provided by the operating system, specifically Presentation Manager. When applications use the standard PM controls it helps maintain a consistent "look and feel" among the applications.

DrDialog supports creating windows and provides all the standard OS/2 Presentation Manager controls, or at least the ones that existed in 1992-1993. The controls supported are: the push button, check box, radio button, text box, notebook, container, list box, combo box, single-line edit, multi-line edit, spin button, value set, vertical and horizontal scroll bar, slider control, group box, menu (pop-up and normal), frame, and the standard file prompt dialog box. In addition, DrDialog provides some special, non-standard Presentation Manager controls:

• Bitmap button - for creating buttons with a bitmap graphics on them.
• Bag button - for grouping multiple controls together on a button.
• Turtle control - this control processes a file which contains drawing commands for creating an image on the control. The drawing commands are similar to what you would use with a pen plotter: pen down, pen up, move left, move right, etc. This control can be used as a background containing other controls, or by itself.
• Marquee control - a vector based text control. This allows the text to be sized smoothly when the control is sized, and provide embossed and engraved styles in addition to normal, bold and italic.
• Billboard control - displays a bitmap image. This control can also be used as a background for other controls or by itself. The bitmap can be scaled, replicated, and set to scroll in a direction or stay stationary.
• Canvas - very similar to a group box but provides more 3D-like styles to the surrounding box.
• Paint control - used to provide a background color for a dialog.
• User defined control - the actual window class can be controlled by the "style" setting. I have not used this control. While it looks like this might be used to incorporate new PM controls when they come along, I cannot comment on it.

Each window, along with its controls, is called a "dialog" in DrDialog. A single DrDialog application can have multiple dialogs. Each dialog and control is automatically assigned a unique numeric ID. You can change that ID or optionally assign a name to each control and dialog. You use these IDs and/or names to refer to the dialogs and controls in your Rexx code.

Each control has a number of "events" defined for the control. These are triggered when the user performs some action on the control, such as click, size, select, etc. Each event can have Rexx code attached that DrDialog executes when the event is triggered. In addition to the "normal" events you see in all the other RAD products, DrDialog also provides events for drag and drop. The drag and drop events allow you to design a dialog where the user can drag and drop controls onto other controls, or items from a container onto other controls or container items.

The runtime environment is the "glue" that binds together the controls, the events, and the Rexx code into a working application. It displays the dialogs, handles the events, and calls the appropriate Rexx code. It also automatically resizes and repositions the controls in a dialog when the dialog is resized, although you can override that positioning and do it yourself if you don't like the way the runtime handles it.

The runtime is multi-threaded so that the application remains responsive to the user - the Rexx code that is executed for events is run on a separate thread from the one that handles the display of the dialog. In addition, DrDialog provides some functions and facilities for writing multi-threaded Rexx code in the application. This can speed up an application or handle requirements such as allowing the application user to cancel a long running process.

Rexx Code

The Rexx code you write in a DrDialog application falls into two categories: event routines which are Rexx procedures directly attached to an event, and global procedures. Event routines are called (actually SIGNALed) by the runtime when the event happens; global procedures are only called by you in your event routine, using a CALL statement or as a function call. (The one exception to this rule is when the application starts up - if there is a global procedure called INIT then it is called at start-up.)

Event routines and global procedures are combined into a single Rexx program. This means all Rexx variables are global, visible everywhere, unless you use the Rexx PROCEDURE statement to isolate a procedure's variables. You can only use the PROCEDURE statement in global procedures - not in event routines.

Parameters are never passed into event routines, instead you must use DrDialog provided functions if you need to access data in a control. Functions are provided for almost everything you can do with a control except for creating new controls or destroying existing controls or dialogs. For example, the functions available for a list box control are:

• Add - add a new list box item.
• Delete - delete one or all list box items.
• Select - get/set the select state of a list box item.
• Style - get/set the list box control's style mask.
• Font - get/set the text font used in the list box.
• Color - get/set the color.
• ID - get the ID from the list box.
• Position - get/set the list box's position and size.
• Hide - hide the list box.
• Visible - make the list box visible.
• Top - make the list box the top-most control.
• Bottom - make the list box the bottom-most control.
• Enable - enable the list box.
• Disable - disable the list box, preventing user interaction with it.
• Focus - give the list box the input focus.
• Drag - enable/disable dragging the list box control.
• Drop - enable/disable dropping on the list box.
• isDefault - routes Rexx say statement output to the list box, and/or makes hint text appear in the list box.
• Controls - get a list of all the dialog controls.
• Classes - get a list of all the dialog control classes.

You invoke these functions using a simple object oriented naming convention:

DialogName.ControlName.Function

where DialogName says which dialog the control is in, if the application has more than one; and ControlName specifies which control you want to invoke the function against. You can use either the dialog/control name, or the ID number for the dialog/control. This simple naming convention allows you to call functions for any dialog and any control from anywhere in the application.

External Rexx procedures can be called from event routines or global procedures. This means you can make use of any Rexx function or procedure that is normally available to Rexx. This includes, for example, the DB2 and Oracle Rexx interfaces, the RxSql and Rxu libraries, TCP/IP, FTP, UPM and the Lan Manager libraries supplied with OS/2. When the external Rexx function RETURNs, control returns to the event routine or global procedure which CALLed the external function.

Output from any Rexx SAY statements can be routed to any text type control in the dialog; if not routed the output appears in a window supplied by the runtime. The runtime will also open a window to request user input from Rexx PULL statements.

The Development Environment & Tools

The DrDialog environment presents a very spare, uncluttered look; when you first start it up it opens with just a new blank dialog loaded and a menu bar.

You use pop-up context menus or the menu bar to access the tools you need. When you finish with the tool it disappears.

You can configure DrDialog to have the more "conventional" look and behavior of multiple tool bars using the Systems Menu of the various tools. Unchecking the Auto Hide option prevents the tool from disappearing when you are done with it, and checking Auto Open causes the tool to appear when DrDialog starts up. You will mainly use 4 tools to create applications. Each of those can be configured as floating tool bars: the Controls tool to place controls on a window/dialog, the Group tool to adjust and position those controls, the Rexx tool to enter Rexx code an attach the code to control events, and the Run tool to execute and debug the application.

]

The steps for building an application are:

1. Create a dialog.
2. Place controls on the dialog.
3. Create Rexx code for the controls' events.
4. Run and debug the application.

We will discuss each step below.

Creating Dialogs

DrDialog automatically creates a new blank dialog when it opens, but you will need to create additional dialogs if you application requires more than one window. Additional blank dialogs are created with the Dialog tool, which is also used to select the current dialog you want to work with and to unhide dialogs if you have hidden them.

The Dialog tools lists all the dialogs in the application, along with their IDs and optional names.

The Grab Tool

If there is another application with a window or dialog box that is close to what you are trying to create, you can copy that window along with its controls into DrDialog as a new dialog, rather than creating the dialog from scratch. This is done with the Grab tool, which can "grab" windows, individual controls, and menus or menu items.

[grab_results.gif ]
[Click on screenshot to view full-size.]

The Grab tool sometimes works and sometimes doesn't. It appears to only work on standard PM controls, i.e. controls specified as "resources" and compiled by the resource compiler; some newer applications built with the IBM Open Class library from VisualAge C++ do not use standard PM controls but rather build windows and controls that function somewhat like standard windows and controls.

Placing Controls in a Dialog

You create a control by dragging it from the Controls tool and dropping it on the dialog.

Right-clicking on the control displays the context menu where you can set various "properties": ID, name, text, and "styles" which effect the appearance of the control. Controls are sized and moved with the right mouse button.

The Group tool can be used to position and size controls. There are the usual center, left align, right align, make same size, etc. functions. In addition there is a function for copying the style from one control to other controls, mainly useful for groups of the same control, such as buttons.

You can quickly switch from edit to view mode using the View tool. This does not run the application but simply presents the dialog as the user will see when it runs.

Entering Rexx Code

Once you have the controls created and arranged, you enter Rexx code to handle the events with the Rexx tool. If you remember from the previous section there are two categories of Rexx code in the application: event routines and global procedures. The Rexx tool is structured with a section for each of the two categories, accessed by the tabs on the bottom of the notebook. There is also a third section for entering and storing snippets of Rexx code that you may want to keep handy. It basically functions as a persistent clipboard where you can store snippets of code for copying into event routines or global procedures.

In the events routine section the main page lists the active dialog and all its controls, as shown above. Double-clicking on a line in the list switches the notebook to that control's section, which has tabs running down the right side for each event recognized. Clicking on the tab for an event turns to that page where you can enter Rexx code to handle the event. The tabs with asterisks in them have Rexx code entered.

]

Each event page contains a simple editor you use to type in Rexx code. If you don't like the DrDialog editor, you can use your own editor to type event procedures. Pressing the Copy to Clipboard icon (second from top left) when no text is entered will cause DrDialog to enter a call statement in the event, and place in the clipboard a matching label, which you can paste into your editor to start that procedure. Each time you run or save the application DrDialog will copy the code from the external file into the application.

The second section of the Rexx tool is where you work with global procedures. Each procedure is represented by a tab on the right side; clicking the tab takes you to that procedure's page.

New procedures are created by entering a name in top line and pressing Enter. In this example there are three global procs: Init, Main, and Show_Existing.

Part of the idea behind global procedures is to reuse Rexx code among multiple applications - you put the bulk of the processing in a global procedure and CALL into the procedure from a control's event code. For that to work, the code must be accessible to more than one application. To that end, DrDialog has a RexxLib tool which creates a "library" of Rexx procedures that can be shared among applications, much like a library for compiled code.

You create the Rexx procedures with your editor, save to a file, and drop the file on the RexxLib tool to enter new procedures into the library or update existing procedures. The code must be written as Rexx procedures, each procedure beginning with a label and ending with a corresponding RETURN. The label names must begin and end with an underscore: e.g. _myproc_. When the RexxLib is open, the window shows a list of the procedures on the left with the code making up the selected procedure on the right.

Once you have a library created, you run the RexxUse tool to synchronize your application with the library code. The RexxUse tool analyzes the Rexx code in your application looking for instances where library procedures are used. Library procedures that are CALLed or referenced as functions in the application are added as new global procedures or updated from the library. Global procedures that are no longer referenced by the application are deleted from the application. This figure shows that two library procedures have been copied into the application as global procedures. I had to put statements calling the two procedures in the application for them to show up. Before using the RexxUse tool you need to save your application so that all the latest changes are saved to the .RES file where the application is stored.

Finally - there is a ResToRxx tool which will extract all the Rexx code from the DrDialog application into an external file. The file will have the same name as the application but with an .RXX extension. It is often times much easier to track down problems when looking at the whole code than to search through individual pages in the Rexx tool notebook.

Testing the Application

Once you have written the Rexx code for your application you need to run the application in order to debug it. The Run Tool is used to: run the application, step through the Rexx code in tracing and debug modes, view the current values of Rexx variables, and execute Rexx statements while the application is running.

Clicking the running man icon at the bottom of Run tool screen will run the application. You can switch from normal mode to various debug and trace modes using the drop down list and icon on the upper left. The single line text entry area in the middle is where you can enter any Rexx statement, and have it run by clicking in the math symbol icon to the left. Finally the Variables drop down list will list all the Rexx variables in the application with their current values.

Switching from edit to run mode is very fast since there is no compiling - one of the advantages of using Rexx.

Converting to an OS/2 Application

DrDialog applications are stored in a binary resource file with the extension .RES. To distribute the application to other users you have two choices:

1. Distribute the .RES file containing the application, along with the runtime DrRexx.EXE. If your application uses any DrDialog specific controls you also must distribute DrDialog.DLL.
2. Convert the application into its own executable using the ResToRexx tool. The converted application needs no runtime; however if it uses any DrDialog specific controls is also will need the DrDialog.DLL file.

Converting the application into an executable file consists of dragging the .RES file onto the ResToExe icon in the DrDialog folder. You must have the resource compiler from the OS/2 toolkit in your path for the ResToRex tool to work. The resource compiler must be from the version 3 or earlier of the toolkit - the resource compiler from the version 4.0 and higher Toolkits will not work.

In both cases if your application uses icons or graphics you must either include each graphic file with your application, or convert the images into a DLL using the BMPtoDLL tool. If you convert the images into a DLL you just have to distribute the one DLL instead of each individual graphic file. Each control that uses graphics can reference those graphics either from a DLL or as individual files. I have also used the BMPtoDLL to create DLLs for icons and graphics for use with VisualAge C++, no fuss, no muss, no writing fako functions to force the creation of a DLL of resources. BmpToDll is a command line tool.

If you are going to be the only user of your DrDialog application you can drag the .RES file to the RexToPgm icon to create a Workplace shell icon for the program.

Support and Pricing

Free - no support.

How Does It Stack Up?

If you compare DrDialog to other Rexx RAD tools it comes out a little sparse. It does not have a graphical database designer or report writer like VisPro/Rexx, and it doesn't have ODBC database access like both VisPro and VxRexx. On the other hand, it is available and it works, unlike VxRexx. And it is free, although price is much less important than the functionality of a product - if a tool is no good, it doesn't matter if it is free.

DrDialog's strong points are:

• It is very easy to use.
• It has a very complete implementation of PM controls - the container control even allows editing of the contents in detail view.
• It is based on Rexx. Every Rexx utility package, Rexx enabled application interface, and Rexx enabled OS/2 API can be used in a DrDialog application.
• It is extendable using the DrsAide tool and hooks.

DrDialog's weak points are:

• It is based on Rexx. Rexx is an interpreted language and is not appropriate for all applications.
• It is missing some controls that are now considered standard, even though they are not Presentation Manager controls, such as a split canvas/window.
• It takes a little extra coding to fill list boxes and the like from a database when compared to "database enabled" controls.
• It is not supported.

The last item probably causes the most heartburn for people, and yet I think DrDialog is a better product today than it was 8 years ago. Not because DrDialog has changed, but because the world of Rexx has changed. Since DrDialog was released, Rexx has morphed into an object oriented language. Rexx now has a fairly complete interface to SOM and the Workplace Shell, along with interfaces to TCP/IP and FTP, neither of which completely existed in 1993.

Perhaps the bigger question is "Is there a place for Rexx in today's Java world?" I believe the answer to that is yes, especially in the OS/2 world. Consider that a fairly big DrDialog application results in a .RES file size of 10K. In a corporate intranet environment you could distribute the DrRexx.exe file (about 170K) to your clients and serve the DrDialog application, the .RES file, from a web server. With a 10k download you could have a graphical program that retains the look, feel and responsiveness of a native program - because it is. Try that with Java.

Where to Get it, and Other Things You May Need

DrDialog is available from Hobbes, OS2BBS and LEO, as well as a number of other sites.

If you are using DrDialog with Object Rexx you will need DrDlgFix.zip which corrects a problem with the DrsAide tool and Object Rexx.

You will need to obtain an old version of the resource compiler to use the ResToRexx tool. Try DrDlgRc.ZIP on Hobbes, OS2BBS and LEO. This should also be available in the eComStation distribution, although you will have to search for it since it will be in the archived tools section. I have not confirmed this however.

If you are writing help for your application you will need IPFC.exe, the help compiler, to create help screens. That comes in the OS/2 Toolkit. Any version will do.

The Rxu utilities package is available from Hobbes, OS2BBS and LEO. This package contains Rexx versions of many of the OS/2 API functions.

VRexx is a package that provides a simple programmatic interface to Presentation Manager. It provides PM features that aren't in DrDialog, e.g. creating a window and drawing into the window with GDI functions.

The CUA design guide is always handy to have around, in case you can't remember the capitalization rules for menus and dialog boxes.

---

DrDialog

• Price: Free
• Download: http://hobbes.nmsu.edu/pub/os2/dev/rexx/drdialog.zip