SB Gogia

Coming to the basic object of this paper: if such an editstyle control is available as a part of the DataWindow editable objects it would largely obviate the huge code that we needed to generate. Such a control would only be an extension of the current dropdown list box. (At one point, we got the message from PowerBuilder - PowerBuilder Allows only 255 lines of code that we had apparently exceeded - so we were forced to create a new function - uf_createlist instead of_createlist - that performed exactly the same function but was called through different userobjects/DataWindows.)

In case the data value of each choice is a single character (which has to be unique) there would be no need for a terminator character. The data would be stored only as a concatenation of the selected choices with the same choices being highlighted as soon as the focus is put on the column. If the option "always show list" is exercised, the need for a computed column is obviated.
If the choices have a data value that happens to be longer than one character, a terminator character is needed - we used the semicolon, but such a choice can be put to the developer. Back-end coding for creating the data should be fairly standard.

Appendix I
Description of the sample code provided in CodeXchange.

Basics
•   PB version 9.02 Build 7554
•   Database ASA
•   Connection through dbconfig.ini
•   Database file research.db

Our Basic Workflow
The main window (w_research) provided has a tab_main object in which the first tabpage (uo_pt_search) is used to select the patient for whom the data is required either by a scroll or a search (menu not provided in the current sample). The other tabpages will retrieve or display the data of that patient (whose row is highlighted) on opening a small display DataWindow (d_pt_identity ) and will show essential details of the selected patient as the footer of the window. Comments are provided with each object.

The Objects
In brief - the need was first felt when we tried to give a choice of clinic days for a doctor so that appropriate appointments could be made during the days he was present (d_doc_timings). Later when the choice had to be extended to many more columns, we felt a dropdown list box could offer graphical choices if required. Once adept, or by choice, the user could type in the choices manually (DAS 28 - or object uo_mal_history) - in all the editable columns that use a common list box that (uo_jt_findings). So the coding is done in the same object without much need for inheritance.

Over a period of time this type of choice was extended to many objects - a representative base sample is provided (uo_missed_diag_study) for a study of patients with Ankylosing Spondylitis using a list box (uo_missed_diag) wherein the different column specification was coded in four places:

1.  In the Itemfocuschanged event of the DataWindow - where the specified column using the list box invokes the display of the list box and calls the functions below
2.  A function called of_create_list creates the list of items to be made for this column
3.  A function called of_show displays the selected items based on the data
4.  The selection_changed event of the list box puts the data back in the column based on the selection (it uses a small inline function - of_make that just has one line - i_dw.settext(isRtn) - meaning populate what's created into the calling column

The length of the column has to be more than the total number of options and can be of the Char or Varchar type. In each case the DataWindow has a computed column next to it to display the exact choices as selected. Some columns that have a choice of <Others> will allow entry of data to describe the others as a separate data column.

A separate type of list box (uo_alter_diag) that enters the entire text of the choice to allow some minor editing later is also displayed in uo_missed_diag_study.

A command button (cb_done) has to be clicked to close the list box. This is necessary only if one is providing a choice between a manual and graphical list box entry.

All the coding above will decrease markedly if a multi-select list box is offered as a DataWindow control. The options the user has to fill will be: Display the value of each item, the data value of each item, and the separator of items (in case the data value isn't of type Char.).

PowerBuilder can internally generate the other scripts (the four examples mentioned above). If the permanently displayed option (Always Show List) is used or made mandatory for multi-select list boxes, the need for a computed column alongside may be obviated.

All the items have relevant comments and while some have further documentation within the object itself.