Beginning with Tk 8.3, the entry widget has built-in hooks for validating the contents of an entry.By adding a little code to the entry widget, you can check the entered data on the fly.
DKF adds: If you have some complex string that you are needing to enter, then you might prefer to perform validation on some criterion other than a key press - it is easy to imagine that the requirement that an entry have a minimum of 4 characters in it will be violated when you are entering the first of them - and it is even possible that you will want several different kinds of validation, depending on whether it is triggered by a key press (when you check to see if the key is a reasonable thing at that point) or, for example, a focus-out (when you check to see if the contents really is valid overall.)A deeper question is how you report a validation failure to the user.
Popping up a dialog box to report the failure is probably not a good idea, especially if the user hasn't finished with the form just yet!
From what I've seen in practise and read in the likes of About Face, I'd say that the best technique is to be as lenient as possible with typing during the main part of the data entry, indicating failed validations using subtle hints (e.g. ]LV And using colors as indicators will of course be frustrating for someone who is blind (either legally or just color blind...).
by changing the colour of the associated label from the usual sedate black on grey to red on grey) and only when the whole form is accepted by the user should you perform any more stringent validation, and failures should be reported by sounding the bell (never neglect the power of aural feedback) and moving the focus to the first of the fields whose validations failed (though all should be marked.) Reserve dialog boxes for when a particularly complex and rarely-failed validation doesn't work, since dialogs are really disruptive to people's workflows and have only limited pedagogic value (these particular dialogs are also ideal candidates for being switched off individually by users.)[ AK -- Regarding aural feedback ... And people will not like it if their problems are announced to the world around them. When you have fields that are co-validated, you must always validate them as a group, even for trivial changes (since a change to one might make a previously invalid field become valid, or vice versa.)If you've taken the time to add an online-help system to your application, then that help should describe what sorts of validations are being done.
Like that, anyone who forgets how a particular validation is done (from their perspective obviously; only a programmer would like to see the regexp being used!
) can remind themselves with the press of a key or the touch of a button.
KBK observes further: At one point, I had a customer who wanted an entry field that would validate a time of day (HH: MM: SS); actually, since the application was for video processing, the time also included a frame count within the second, but that's not really relevant to the discussion.
Feel free to add more validation examples that you find useful.
Also, be aware that Wcb is a script library that you may find useful for these sorts of things.
It is worth noting that some of the regular expressions look a little odd.
The Real Number expression, for example, will allow -9.9.e-9 if you are checking any string with ''regexp' (which is why I've replaced it with a simpler validator - DKF.) But you cannot progressively build up to that string. ) The validation command must be defined in the context of the mode defined by the -validate switch.