Is avoiding raising an event when it is not needed considered premature optimisation?

Question

I have a custom TextBox that validates its input. Whenever the validity of the input changes, a ValidityChanged event is raised and the user is informed about the validation results. My question is what to do when the user changes the input, but the input still has the same errors.

For example, let's say the input should not exceed 3 characters and should contain only non-numeric characters. Now let's say the user enters 4 numeric characters. ValidityChanged is raised, and the user is notified of both errors. However, he is adding another character. The errors are exactly the same (longer the 3 characters, contains numeric characters), so there should not be an extra notification.

In that case, should I even raise ValidityChanged? Or should I check first if the new errors are the same as the previous ones and raise the event only if the errors are different or is that premature optimisation?

Answer 1

All that matters is why you raise the ValidityChanged event.

As the name suggests, it's when the Control goes from being "valid" to being "invalid" or vice versa. What causes it to change is irrelevant; the fact that it has changed is all that matters to the event.

If you're raising these events as the user types then the chances are they're going to get a few of these events in rapid succession. That's only a problem if the consumer of said event does something "stupid" with it, like displaying a dialog if the control is invalid but - Good News - it's not your [immediate] problem.

... say the user enters 4 numeric characters.

Surprisingly, a user cannot [easily] do so. They can enter one character, followed by another, followed by another (unless they paste in a complete, new value, all in one go). Each [single-character] changed is examined by the control and its overall validity evaluated. If that validity changes then you raise the event.

Perhaps your difficulty is that you're asking the ValidityChanged event to be too helpful and trying to "explain" what's wrong with the control.

I would suggest that that's the job of a separate property on the Control, which describes the error[s] afflicting the control at that time. Any handler of the ValidityChanged event would be able to examine this property for the gory details.
Alternatively, your ValidityChanged event might include those [changing] errors, but then you have to raise the event every time those errors change as well as for the overall "valid-ness" of the control.

Answer 2

I wouldn't raise the error in the first place.

The text in the text-box is new, hence why you need to re-validate the text and but not raise the error. But you have to inform the user. Validation routines shouldn't raise errors like that because non-valid text is an expected condition.

What you have to think about though is: how am I going to inform the user. A popup in the scenario is unwanted because I wouldn't want to close a popup after every letter I type. A green check-mark/red cross next to the input that changes depending on validity works. This you would do for any change in the text-box.

Only when submitting the form raise it as an error. Because it is an error to try submit mal-validated data. (I use this word to show the data is checked but didn't pass validation, which is different from un-validated data)