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?

  • 1
    Raising or not raising an event changes the meaning of your program. Most likely only one of the two behaviors correctly implements the (no doubt implicit) specification, in which case deciding between them is not a matter of performance. Optimizations don't change behavior/meaning. Decide what you want the event to mean and then implement the code accordingly. Dec 16, 2017 at 0:29

2 Answers 2


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.

  • 1
    Thank you so much! I actually do have another property that holds the errors: Failures. But your answer made me realize that the name of the event is actually wrong and should be FailuresChanged or something like that. Thanks! Dec 15, 2017 at 13:27

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)

  • Thanks! You are correct. I inform the user about the error using the C# ErrorProvider which show a red icon near the TextBox and show the errors when hovering the mouse over the icon, I am not using a MessageBox. Look here: r4r.co.in/c1/01/tutorial/csharp/image/error5.JPG Dec 15, 2017 at 13:06
  • I'd question why you can even submit a form with invalid data in the first place. Or that it should be treated as an error. If you do have a scenario where you can accept invalid data then I'd posit that at best its a warning that the user needs to acknowledge before accepting said data.
    – Peter M
    Dec 15, 2017 at 13:37
  • @PeterM you need to validate at all stages. You shouldn't be able to submit a form with invalid data but also, receivers of that data shouldn't accept invalid data also.
    – Pieter B
    Dec 15, 2017 at 15:41
  • I agree with you on that. But I got the impression from your answer that it was the UI and not the BLL that was raising the invalid form data error - especially as the topic seems to revolve around the UI layer.
    – Peter M
    Dec 15, 2017 at 18:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.