A Better Way To Write Pick/Browse Lists [4/4]

Over and over again, a user must enter one of a set of legal values, depending on the column for which that value is destined. Several years ago we developed a structure called the field option group (fog), rather like an enum in C, and encoded it in dictionary tables in our database. It contains codes and descriptions for all the available values of a column in the database. By using gvs, our current fog system presents standard and uniform picklists to our users, and reduces programming effort on our part. If you want your data entry clerk to enter a legal value, simply call get_value_picklist(tablename, fieldname), and the fog system gathers the legal codes and descriptions for that table and column, passes this view to gvs, generates a picklist, asks the user to select one, and returns the selection to the calling function. A similar call enables the clerk to select multiple options (e.g. which forms of anesthesia were used during an operation). This function calls the same gvs system, passing PICK_MANY instead of PICK_ONE. It also passes a function pointer that you specify, the function that implements the select/unselect capability, usually via inserts and deletes. This means we may change the set of legal options for any column without doing any reprogramming or recompilation. Because the ubiquitous sql calls degraded performance, I wrote a C caching system over top of the fog system. Once a fog value is fetched from the database it need not be fetched again. If fog entries are changed, this fact is not presented to the user until the program restarts. We feel this is an acceptable compromise. I should mention that advances in database technology will bring significant enhancements to our fog system. Data integrity demands we take advantage of check constraints, and these inevitably mirror our fog values. I have already written a utility that reads the fog values and constructs an sql statement that creates the corresponding check constraint. It will take a little more work to write the full scale audit, but it is definitely on the horizon. Finally, I would like to describe our table driven menu system. Using a `menu' table and a `menu_option' table, we link several options to each menu at the database level. Each option contains an action code or another menu number. The menu number acts as a submenu, causing the user to descend to that submenu when he selects that option. Thus our collection of menus is a giant digraph. If the selected option contains an action code, this code is passed to your menu_action function, which you supply. Do a switch on this code and take appropriate action. To begin the menu system, starting at menu 27, call tb_menu_manage(27). The library handles all the menu screens and traverses the menu tree without your intervention. When the user finally selects an option that requires an action on your part, tb_menu_manage() calls menu_action() with the action code. With this system, one can completely restructure the menus without changing any software. Admin tools make this task relatively easy. Again, the system is flexible as well as maintainable. Some of our programs start at different root menus, depending on the user. Perhaps a secretary sees a restricted menu, while a supervisor sees a complete menu tree. An option can take the user from a fifth level menu back up to the root menu (the software handles cycles in a sensible way). Without any additional programming effort, control U, from any gvs screen or any menu, sends the user into a "utility menu". Most applications set gvs_umenu to a particular Unix menu, with options for mail, word processor, change password, change default printer, etc. Control P from any gvs screen prints the entire screen to your default printer. If you want a copy of what you are browsing through, just hit control-p. The gvs package contains many other features as well, but I think I should stop here. Please contact me directly if you are interested. -- I do more all day -- than most people do before 9 A.M. Karl Dahlke eklhad@siss81.sis.rpslmc.edu (312) 942-8040