Re: Field-level validation

[Steven Brooks <umbrook0 cs umanitoba ca>]

> Interesting. 
>
> I'd have to say that I think application should be an application
> level thing and applications should generally display a dialog saying
> what failed to validate, rather than just not allowing the user
> to tab out.


That can be done as part of the "validate" signal, or a
"validate-failed" signal could be added.  The details of signalling the
user should be left to the application developer (for example, the
status bar or audio feedback could be used instead of a dialog,
depending on the application and environment).

> (Which generally means doing validation when the user clicks OK,
> rather than on focus changes. Actually, it's best to design your
> interface so that the user can't enter invalid date in the
> first place.)


As for validating when the user clicks OK, that's a valid technique,
certainly.  But field-level validation can also be useful, especially
if fields are inter-related, or if the program is trying to fill in
future fields based on the current field.  Obviously a wizard (druid) is
a similar solution -- but it tends to introduce data hiding, where the
user can no longer see all of the data that they've entered to get to
this point, and they have to go hunting if they want to change some
earlier entry.

Forexample, what if the field contains sales order numbers from a large
database?  The user wants to just type in the SO number and quickly
load the data.  Preloading a combobox with all the sales order numbers
from a large database may be impractically slow -- especially on a WAN.
Instead, you look up the number entered as they leave the field.

Another example is the user is adding an order line to a work order.
An inventory item is added by typing in its number.  The program
validates the number and automatically adds the assembly information for
that inventory item.

Focus-out doesn't work because the focus has left the field at that
point, and you have focus jumping around.  You'll get flickering, or if
you are performing actions on focus changes, potential program failures.

Errors-at-the-end don't help smart programs, and can be annoying in
data-entry work.

> Putting this into the core of GTK+ doesn't really seem appropriate
> to me. Are there other toolkits that do this?


Visual Basic 6 does.  I don't know of any other toolkit -- it's
something that the company I'm working for always has to add in
themselves.

Whether hypothetical widgets like ``GtkValidatingEntry'' should be
included is arguable, but I think the raw capability needs to be
included so that there is at least a possibility of doing field-level
validation with GTK+.

Thanks,
Steven