A Practical Use for Named Events

By Peter van Dam (published in 1999)

When programming small utilities for a specific task, such an import or conversion utility, I have often faced the dilemma of how to provide feedback to the user. Sometimes I want any messages to appear on the screen so I can decide how to continue. On other occasions I don't want the process to wait for my reply and prefer any progress information displayed in a down frame. At the same time it should be possible to run the program in batch mode or on an Appserver where you need to catch the messages to write them to a log file or error queue.

Another type of information we all sometimes love and sometimes hate is debug information. This is information you only need when tracing a problem. Sometimes a few strategically placed messages can solve your case but if it gets really complicated you want all the information you can get. Have you ever found yourself adding and removing the same debug message statements in the same program over and over again?

In Progress v9 all of these dilemmas are resolved with one simple statement: PUBLISH.

The system described here is used in the WALVIS Progress Platform as well as the BDK and is based on the association of a level with each event. That is, the description of each event such as error, warning, information or debug is published with an appropriate level that can be used by the subscriber to filter the information. The following table lists a possible classification:

Level Meaning
0 - 9 Error
10 - 19 Warning
30 - 39 End results
50 - 59 Intermediate results
60 - 69 Detailed intermediate results
70 - 79 General debug information
80 - 89 Detailed debug information
90 - 99 Very detailed debug information

Anybody who is interested in some of this information can subscribe to the event and process the data according to the specific needs at the time without ever modifying the program itself. For example, a calling program could display the messages with a level between 50 and 70 in the status bar of a window so a user can monitor the progress of the operation if it is run interactively. When run in batch another handler could write all messages with a level between 0 and 30 to a file that is subsequently emailed to the requesting user. When run on an Appserver the errors and warnings could be written to the appropriate message queues.

Should the need for debug information arise then an additional debug message handler could be started to process that information. This debug handler could include a user control enabling the developer to adjust the level(s) for which messages are displayed dynamically.

On www.v9stuff.com another example of the application of this principle can be found in dbwrite9.p, a utility that uses dynamic queries and buffers to write any fields of any selection of any table(s) in your database to disk in dBase format. Download this utility and start it against the Sports database in the following way:

subscribe to "dbaseInfo" anywhere. 

run dbwrite9.p ("customer, state","","").

procedure dbaseInfo:

define input parameter level# as integer no-undo.
define input parameter info# as char no-undo.

if level# < 60 then
message info# view-as alert-box
title substitute("Level &1 dBaseInfo message", level#).

end procedure.

Now play around with level# and the program code to get completely different results without ever touching dbwrite9.p and you will soon realize the power of this loose coupling approach.