Ask Reuben
GUI Widgets in a Construct
Why does a COMBOBOX allow you to select multiple values in a CONSTRUCT ?
Why does a RADIOGROUP allow all you to select multiple values in a CONSTRUCT ?
Why does CHECKBOX allow 3 values in a CONSTRUCT ?
How do you validate values a user enters into a CONSTRUCT ?
How do you limit what is entered in a CONSTRUCT ?
An observation that an end-user may make is that a COMBOBOX in a CONSTRUCT allows the user to select multiple values whilst a COMBOBOX in an INPUT, only one value can be selected.
In the screenshots below the first image is from an INPUT and only own row can be selected. In the second image which is from a CONSTRUCT, each item in the COMBOBOX is rendered with a little check-box that indicates if the row is selected and multiple rows can be selected.
Similar observations can be made with other widgets.
With a RADIOGROUP, in an INPUT only one value can be selected, and selecting another value unselects the current selection. In a CONSTRUCT, the user can click and select multiple values and the current selection(s) are retained.
The first screenshot is from an INPUT with one value selected, the second is from a CONSTRUCT with multiple values selected.
With a CHECKBOX that has NOT NULL defined, in an INPUT a CHECKBOX will toggle between two states to indicate the selection of the VALUECHECKED or VALUEUNCHECKED attribute. That same CHECKBOX in a CONSTRUCT will toggle between three states.
The first screenshot shows two checkboxes corresponding to VALUECHECKED and VALUEUNCHECKED. The second screenshots also shows the third state that is available in a CONSTRUCT. (Note: this third state also represents NULL in an INPUT that does not have NOT NULL defined)
The reasoning for this can be found in the original Informix-4gl TUI interface. The TUI interface allowed the user to type in QBE criteria such as COMBOBOX and RADIOGROUP have typically been used for form fields where in the previous 4gl TUI interface, the code might have included an attribute such as INCLUDE=(1,2,3,4,5). This translates to ITEMS=(1,2,3,4,5) with COMBOBOX and RADIOGROUP. With the introduction of GUI widgets, it is desirable that in a CONSTRUCT that the user can enter as much of the QBE criteria they could enter in a TUI widget, after all the movement form TUI to GUI is supposed to be a step forward. So where the widget behaviour allows, we have tried to find ways that a user can enter QBE criteria that they could in a TUI environment. In a COMBOBOX, this means in a CONSTRUCT adding the checkboxes in each row allowing individual row(s) to be selected. In a RADIOGROUP, this means in a CONSTRUCT allowing the user to select multiple radiogroup buttons. In a CHECKBOX, this means toggling to the third state to indicate both values. Not all widgets have a suitable interface. For instance a SLIDER does not have a suitable interface to indicate multiple values selected. Where native widgets have been, as occurred with the native interface that preceded Genero 4.00 on desktop and also Genero Mobile it was not possible to change the native widgets to have a suitable user experience. With Universal Rendering and the use of web technologies we have a lot more control over the user experience In moving from Genero 3.X using native rendering to Genero 4.X using universal rendering, this ability to select multiple values in a COMBOBOX is often commented on. The user might not have had the ability to select multiple values in a GDC or Mobile user interface but they did in the TUI screen that preceded it. If it is desirable that you restrict the values entered in a CONSTRUCT to one value then you have two options available to you. The first is to enter some logic into the AFTER FIELD or AFTER CONSTRUCT. There is at least 4 different ways you can get what has been entered into a field in a CONSTRUCT. These include… In your AFTER FIELD and/or AFTER CONSTRUCT add logic that uses one of these functions/methods to get what the user has entered into the field or the QBE criteria that it generates and validate it against the criteria you want to allow. This could include making sure that something is at least entered into the field or perhaps using ui.Dialog.getQueryFromField to ensure that one row has been selected. The second option is to use Multiple Dialog and use an INPUT for any field that you only want one value to be selected. I recall one case had a report program that had something like this … where printer and number_of_copies were COMBOBOX widgets and the value was extracted and trimmed from the variable where_part before it was passed to the database. The native COMBOBOX only allowed one value to be selected for printer and number_of_copies and so this worked with 3.X and GDC. With universal rendering, the user could now select multiple printers and multiple number of copies. The better code to use in this instance involves multiple dialog similar to … With this code technique, you are using INPUT to enter singular data values, and using a CONSTRUCT to enter QBE criteria. With Universal Rendering, we have more control over the appearance and behaviour of widgets. Potentially there is more we can do with widgets in a Construct to allow the end-user to enter QBE criteria. Could a DATEEDIT be modified so that a user can select multiple dates or even a range of dates? Could a SLIDER be modified so that a user can select a range of values? etc. There is also the option of having a dialog to enter QBE criteria rather than trying to modify widgets to enter QBE criteria as illustrated in this Github repository. For those that provide negative feedback about the ability to select multiple rows in a COMBOBOX in a CONSTRUCT, there are options available to you. Deep down, if you are trying to restrict the QBE criteria entered in a field to a single value, then really you should be in an INPUT at this point.
CONSTRUCT where_part BY NAME ON printer, number_of_copies, field1, field2, ..., fieldN
DIALOG
INPUT BY NAME printer, number_of_copies
...
END INPUT
CONSTRUCT where_part ON field1, field2, ..., fieldN
...
END CONSTRUCT
...
END DIALOG