That’s it. The third time you get asked about a particular topic, its time to stop making it up as you go along, and actually write something down. I was asked (again) today by another one of my clients about Validation within Windows Forms. So I am going to take some time to write up my thoughts
First let me say that there are several parts to validation. There is simple user input or "control" validation, displaying of the results of a failed validation, and then the complex business rule or "form" validation. Lets deal with each in turn
Simple user input validation
As you probably know each control in a form contains a Validating and a Validated event. In order to get those events to fire the CausesValidation property on the control needs to be true, but since that is the default, no problems there. Most people start off by using Validating to implement some simple validation rules like making sure that the input is in the proper form. ASP.NET provides the following forms of validation:
- RequiredFieldValidator – Make some input has been chosen for the control
- RangeValidator – Make sure the input is within a specific range
- RegularExpressionValidator – Make sure the input looks like a regular expression
- CompareValidator – Make sure that the input in one control "matches" the input in another
- CustomValidator – Check the input as you see fit
Windows Forms does not provide those controls out of the box. However, there are solutions, as we will see shortly.
There are two basic approaches to validating many controls on a Form. The first is the ASP.NET approach where one or more validators are dragged onto the form for *each* control that needs validation. The second is to use an IExtenderProvider (tooltips and errorProviders are examples of ExtenderProviders). The idea behind a ExtenderProvider is that you drag one component onto the form, and it extends the properties for every control on that form.
Michael Weinhardt wrote an article providing the ASP.NET way. The model was described in a 3 part article as well as the accompanying source code. In the article just look at the first part as 2 and 3 have been obsoleted by newer versions of .NET (2.0).
Billy Hollis wrote an article providing the second way which has since been removed from MSDN. However the WebCast is still around, and the source code can still be downloaded.
The choice between the two models essentially comes down to the percentage of controls needing validation on a given page. If the percentage is large, go with Billy Hollis’ model, if the percentage is small go with Michael Weinhardt’s model. Another reason for going with Weinhardt is if you are building both Forms and ASP.NET applications in order to stay consistent. BTW – I prefer Billy Hollis’s model. His code is in VB.NET, but I ported it to C#.
Displaying errors
Most everyone agrees that the ErrorProvider is the right way to signal errors in Windows Forms. However some people feel that novice users won’t be able to tell what the error actually is. If your application is meant to be used by novices there are two approaches.
a) build a little framework that dynamically creates an error label with each control that is being checked
b) provide a ValidationSummary control ala ASP.NET that contains all of the errors
I prefer the second option here. Note the Weinhardt’s article mentioned above provides a Validation form which pops up a modal dialog containing the error information, which is another way to go. I dislike modal popups, but I recognize that as largely a matter of taste.
Form and complex business rule validation
Examples of this are the CompareValidator that I mentioned earlier. But here is where the Validating event can really shine. Typically you hook this event and the call into some business logic which tests sums of values, or certain strings when an enum has been chosen above, things like that. The same Validation summary can then be used to display the results of such validation.
Happy Validating!