Validation warnings during input inpolite

[dante]

wrt to, though extends #4427 - when you are entering data into an input (in this case, the first time you focus the input to enter text) it warns you "the value you have entered it not valid" ... seems like an intuitive UI decision would be to wait until blur to warn with icon (eg: LOOK HERE, this input has invalid data) and to give the user the benefit of the doubt while the input has focus(), or simply have a more subtle warning while invalid data is being typed. Perhaps you could incorporate this behavior into whatever decision is made regarding a fix for #4427 ...

[bill]

This is by design, to notify users the instant they type an invalid character, so they know which character is invalid. I don't know, we could have yet another CSS class, or modify the invalid CSS to be more subtle while the field is focused. But it's not just CSS, there's also a tooltip.

I think perhaps what you are really asking for is to differentiate between error values (like "450-326-12x4" for a phone number) vs. incomplete values (like "450-" for a phone number), but that's harder to do.

[guest]

To solve this issue for incomplete values, I can suggest two alternatives: 1. The easier one: have a boolean setting like showErrorMessageOnLostFocus. If this is set to true, the tooltip for invalid value should only be shown once the user leaves the input field and not while the focus is on the field.

2. The slightly trickier one: have a setting for timeDelay. The value in this property will be used to set a time delay before the actual comparision between the value entered and the regular expression takes place. This delay will give time to the user to finish typing the value.

Replying to bill:

This is by design, to notify users the instant they type an invalid character, so they know which character is invalid. I don't know, we could have yet another CSS class, or modify the invalid CSS to be more subtle while the field is focused. But it's not just CSS, there's also a tooltip. I think perhaps what you are really asking for is to differentiate between error values (like "450-326-12x4" for a phone number) vs. incomplete values (like "450-" for a phone number), but that's harder to do.

[alex]

Milestone 2.0 deleted

[bill]

Notes from http://spreadsheets0.google.com/ccc?key=p3oic4WD9C-x4pXrTGo7dBA :

We think it's wise to minimize disturbing the users with error messages before they've finished typing or an error is apparent. A valid case for presenting an error while the user is typing is when you know that the user has typed something that will never be correct (eg an apha is typed in a zip code field). However, if a field calls for 5 characters and user is simply typing the first character no error should be displayed until onBlur or the 6th character is typed.

[doughays]

new validation logic to match partial values

[doughays]

I'd like to get the function provided by this patch reviewed in time for the 1.2 beta. The new function will match partial values and not flag them as errors until the field has been blurred for the first time.

[bill]

Thanks for working on this. The partial value matching is great. The thing that confused me (when I tried it) was how partial matching stops after the first blur. For example, let's say a user types in a value (like 123.45), and then later goes back to the same field to type a completely different value (after erasing the old value)... he no longer gets the benefit of the doubt... the field turns yellow instantly.

ISTM that if a user starts to modify a field (even if the field was previously blurred) the widget should revert to the more lenient partial matching (until another blur).

I also noticed three bugs (in the sense that incomplete values are flagged as errors):

• In test_validate.html, for the elevation field, as soon as you type "-" it goes yellow. Then when you type a digit (so the field becomes "-2") it goes white again.
• In test_DateTextBox.html, for the "American Date" field, if you erase the current value and start to type "12/30/2006", it goes yellow after you type "20" (from the year). Apparently it's "jumping to the conclusion" that the user is typing a two-digit year even though the typing hasn't finished yet.
• In test_TimeTextBox.html, for the "Time using local conventions" (which is american on my machine), as soon as I type "3:" (planning to type "3:00 pm") it goes yellow. Typing "3" by itself is fine, even though that is also an incomplete value.

So basically, the change is good but we are still being too eager to turn a field yellow.

[doughays]

incomplete errors on focus show up as white box with error msg until the error is fixed - rangetextboxes no longer check the range until the 1st blur

[doughays]

added more sophisticated range checking

[doughays]

(In [14142]) Fixes #4437. Creates a parsing regexp for ValidationTextBox? widgets that matches valid subsets in order to mask validation errors during data entry that are only due to partial input.