A series of simple examples should provide you with the information required to create your own validation table objects. We will start this example by not using a validation table at all. Assume we have a data-entry object defined in one of the following ways:
Object oStatus_Entry is a dbForm
Entry_Item Customer.Status
End_Object
Or
Object oStatus_Entry is a dbComboForm
Entry_Item Customer.Status
End_Object
We will not change any of these data-entry objects (DEOs). We will change the validation types used by the Field Customer.Status in the data dictionary. We will start by not using a validation table at all. Instead, we will assign Customer.Status the following check string:
Set Field_Value_Check field Customer.Status to "O|C|D"
By assigning this field, we will get two behaviors:
Before saving this record, the value of Customer.Status must be O, C, or D.
If a user requests a list of valid values, the choices O, C and D will be presented. The DEO class used will determine the type of list that will be presented. If the DEO is a simple entry form, (dbForm), a popup list will appear when a user selects a prompt. If the DEO is a combo form (dbComboForm), the drop-down combo list will contain the valid values. If the DEO is a radio group (dbRadioGroup) with radio forms inside it, the choices will be presented as a radio list. Each of these DEOs knows how to interact with the Data Dictionary in a manner appropriate to its capabilities. This entire process is automatic.
We will now replace the Field_Value_Check message with a Field_Value_Table message.
Set Field_Value_Table field Customer.Status to oStatusTable
This is not enough to run (or even to compile). We must now create an object that can be used by this field. We will do this by creating the global ValidationTable object named oStatusTable as follows:
Object oStatusTable is a ValidationTable
Procedure Fill_List
Send Add_table_value "O"
Send Add_table_value "C"
Send Add_table_value "D"
End_Procedure
End_Object
:
Class Customer_DataDictionary is a DataDictionary
Procedure Construct_Object
:
Set Field_Value_Table field Customer.Status to oStatusTable
:
This provides the exact same functionality as field check validation. Currently, the only advantage of using a validation table is that this object could be used by other Data Dictionary views that also needed access to the same validation types.
In addition, by changing several properties, we can provide some additional validation capabilities. Those properties are:
Allow_Blank_State
Validate_State
If Allow_Blank_State is true, an empty value ("") is also considered to be a valid value. This would now allow the field value to be O, C, D or nothing (presumably undefined).
If Validate_State is set to false, validation will not be performed on this field. Why would you want this? There are times when you want to provide the user with a set of suggested but not mandatory choices. By setting Validate_State to false, you still get access to the lists (popup lists, combo lists and radio lists) but the values in the lists are not required. They are suggestions.
The other advantage of using the validation object is that you may fill your list in a variety of ways. For example, you could load your choices for the following object with a serial list of line-delimited options.
Object oStatusTable is a ValidationTable
Set Validate_State to False // Suggested, not required
Procedure Fill_List
String sStat
Direct_Input "Status.txt"
If Not (SeqEof) Begin
Readln sStat // read first line
While not (Seqeof)
Send Add_Table_Value sStat
Readln sStat // read in a status value
Loop
Close_Input
End
End_Procedure
End_Object
Sequential File Input and Output