Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Scout/Proposals/InputValidation
There have been several issues about the current concepts and implementation of the scout input validation. This page describes the status quo, problems and possible solutions.
Comments
- Validation is done on focus lost or on any key input (getConfiguredValidateOnAnyKey())
Documentation & Discussions
Forum
[1] Summary of problems
- IFormField.getValue() always returns the last valid value and not the displayed value. IFormField.getErrorStatus returns an error, if there is one, but error value
-> Depending on your use case you might need to check the error status before reading the value -> execChangedValue not firing if an invalid value is reverted back to the previous value
- Invalid value set programmatically
-> Because the framework worka with the assumption that only valid values are set in the scout model layer, the framework is acting wired when a wrong value is set. The invalid value is not shown in the GUI, only the error. ErrorStatus and displaytext are inconsistent
- API
- SmartField.execvalidatevalue cannot be used - Update the value of a field during its own execChangedValue() event. - Controlling if execChangedValue() is called or not.
[2] Disable OK Button on error
If there is at least one field having errorStatus with severity equals to ERROR, then the Button OK will be disabled. -> The "Scout way" is to leave the OK button enabled all the time and rather present a error message to the user when he clicks it.
[3] Limiting input in FormFields, e.g.
- suppression of non-numeric input in number fields
- suppression of digits in string fields
- limiting the number of characters that can be entered in a field
[4] SmartField.execvalidatevalue cannot be used
SmartField.execvalidatevalue is final
[5] Not possible to mix execValidateValue and execChangedValue