Four Js Development Tools Forum

Am I right that in a multiple dialog, the 'field' validation on the form is applied at the end of the sub dialog and not at then end of the overall dialog? IE If I have a field (eg NAME) that is in an INPUT that is defined as REQUIRED, NOT NULL and I try to click on a field in a different sub dialog (ie an INPUT ARRAY), then the form validation stops me moving to the INPUT ARRAY sub dialog if the NAME field is blank?

If that is the case are there settings that can be used to move the 'form' validation to the end of the dialog, rather than the end of the sub dialog?
 

yes, you're right. All fields of a sub dialog are validated before leaving this sub dialog end entering another one. This is logically: when leaving a sub dialog the AFTER {INPUT|CONSTRUCT|DISPLAY} trigger will be called. You can not enter this trigger if any constraint is invalid. That's the contract.

No, there is no way to change this behavior.   

Renne,
So if you're 'designing' multiple dialogs, the form field validation needs to be in 4gl code rather than on the forms.

Is this planned to be changed, as (IMHO) I would have thought that with the advent of mutiple dialogs the whole form in effect potentially becomes the 'dialog', not just the sub dialog?

Rene,
Is the recommendation then here to split complex dialogs into smaller units? IE In version 1.3x I currently have one main input statement that controls the input of a buyers name/address and buying parameters and also then an input array that controls the contact methods for that buyer.
In this old pre multiple dialog, the code 'called' a standard address input function and after the final address field called the contact method input, then carried on with the rest of the 'parameter' fields.
It would seem now that I have to split the input into 2 - and to structure the code as:
DIALOG
1) Input of buyer base details
2) Input array of contact methods
3) Input of buyer parameters

Presumably that is the only way I can stop the 'mandatory' parameters from inhibiting the 'flow' from the address into the contact methods.

Lastly, as said above, we had a couple of standard functions that simplified the input of 'common' structures (addresses, contact methods)
 - obviously we then had to try to emulate Multiple Dialog by jumping to the correct fields on the form. The benefit was though, that we had simple self contained functions. Now, is the only way to handle this type of dialog, repeating the same code? IE if I have 5 modules that input an address plus other 'data', do I now have to repeat the address input code in 5 places? Is there a way of doing:

DIALOG
   CALL INPUT FUNCTION 1 (DIALOG)
    INPUT OTHER DETAILS
END DIALOG

...or is the handling of repeated code now expected to occur via compiler 'include' type directives?


 

... this is only my personal opinion but all the form field validation should be in 4gl code. i.e
...

AFTER FIELD field
   CALL field_valid(field) RETURNING ok, error_text
   IF NOT ok THEN
      ERROR error_text
      NEXT FIELD field
   END IF   
...
FUNCTION field_valid(l_value)
DEFINE l_value STRING
 
   IF l_value IS NULL THEN
      RETURN FALSE, %"Error.Field.Entered"
   END IF
   IF l_value.getLength() <=3 THEN
      RETURN FALSE, %"Error.Field.MinLength" 
   END IF
   RETURN TRUE, ""
END FUNCTION

... doing this gives you

• control over the error message that appears
• control over the style of error message that appears (in panel or in a dialog box etc)
• enables you to reuse the function in other places e.g. importing data via a web service, file etc.
• easier code to debug as the validation is in one place rather than being spread between functions and form field attributes

The NOT NULL attribute should be used to alter the physical appearance and behaviour of the widget as in the case of a COMBOBOX, CHECKBOX, RADIOGROUP. 

Reuben

we should perhaps look at this closer.  Many of the design patterns I'd associate with multi dialogs ...


The Starter Pattern as used in reports, enquiry programs ...
DIALOG
   CONSTRUCT ...
   END CONSTRUCT
   INPUT ...
   END INPUT
END DIALOG

The ListBox pattern to emulate a ListBox Widget
DIALOG
   INPUT ...
   END INPUT
   DISPLAY ARRAY ...
   END DISPLAY
   INPUT ...
   END INPUT
END DIALOG
   
The Master-Detail pattern
DIALOG
   INPUT ...
   END INPUT
   INPUT ARRAY ...
   END INPUT
END DIALOG

Related Field validation
DIALOG
   INPUT ...
   END INPUT
   INPUT BY NAME from_date, to_date
      AFTER INPUT
         IF from_date > to_date THEN
            ERROR "From date must be before To date"
            NEXT FIELD CURRENT
         END IF
   END INPUT
END DIALOG

... would be effected by what Stephen has highlighted.  In many cases the user should be able to click from field to field within the dialog and not be faced with the validation appearning "inconsistently" just because the user happens to be moving from one sub-dialog to another, or if they are staying within the sub-dialog

AFTER FIELD field
   CALL field_valid(field) RETURNING ok, error_text
   IF NOT ok THEN
      ERROR error_text
      NEXT FIELD field
   END IF   
...
 
[/quote]
You have to add the call to field_valid() in AFTER INPUT. Otherwise any field not being touched in the dialog would be accepted unvalidated. 
For a while we suggested the trigger ON VALIDATE. This trigger would be called whenever the dialog must validate a field (AFTER FIELD, AFTER INPUT, before calling a action). This little enhancement would make your code more readable (my point of view) and reduce the duplication of the validation code. 

My 2nd try to replay...
You have to add the call to field_valid() in AFTER INPUT. Otherwise any field not being touched in the dialog would be accepted unvalidated.
For a while we suggested the trigger ON VALIDATE field-name. This trigger would be called whenever the dialog must validate a field (AFTER FIELD, AFTER INPUT, before calling a action). This little enhancement would make your code more readable (my point of view) and reduce the duplication of the validation code.

So are you also advocating against defining form fields like table.column?

It seems that there's 'swings and roundabouts' here. I think I would prefer to have fields still defined like table.column rather than formonly.fieldname, simply as my control is then the database itself and I can't get any code that allows a null into a non null field.
Also, the forms allow for basic validation anyway - so why re-invent that in 4gl code? Surely to take that to extreme would stop the use of comboboxes - so if I still do have validation in the form and 4gl, I'd like to push as much to the front as I can. But that is just my opinion.

To me, the problem is in the implementation of Multiple Dialogues - as in working practice, the sub dialogues are merged into a single dialogue. So in the past (non multiple dialogue) the field validation was effectively 'after dialogue'. Now, the validation is 'after an arbirtrary part of the dialogue'. OK, I can also see that this is what I want now, and I may appreciate the way it works in other circumstances - so couldn't the DIALOG attributes be enhanced to say when the field validation is to occure (ie ATTRIBUTES(VALIDATION=DIALOG or ATTRIBUTES(VALIDATION=SUB_DIALOG).

Rene,

... yes, thats the coding standard I'm used to ...

AFTER INPUT
   CALL field1_valid(field1) RETURNING ok, error_text
   IF NOT ok THEN
      ERROR error_text
      NEXT FIELD field1
   END IF 
   CALL field2_valid(field2) RETURNING ok, error_text
   IF NOT ok THEN
      ERROR error_text
      NEXT FIELD field2
   END IF
   CALL field3_valid(field3) RETURNING ok, error_text
   IF NOT ok THEN
      ERROR error_text
      NEXT FIELD field3
   END IF 
...   



... I know, thats why I was requesting it or something similar many years ago when I was a customer.  Read the old genero-customers mailing list