Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Exploring Secrets of Windows Form Validation  : Page 3

If you're tired of writing custom validation code for every input field in your applications—and of fixing the resulting validation errors—then you'll welcome the generic validation engine described in this article, which can automate many validation scenarios.




Application Security Testing: An Integral Part of DevOps

Maintaining External Business Rules
This is arguably the most important element in the scope, but it is quite straightforward with the visual designer of Visual Studio 2005. Not to say that it does not have a learning curve; it does. I urge you to review the MSDN article How to: Add or Remove Application Settings or other sources for details on persistent settings in .NET. Just briefly, .NET stores persistent settings either in the application.exe.config or user.config on your local system. You can access these settings in code through the Properties.Settings.Default object and through the visual designer in the "Settings" section of the project properties. So, storing business rules as persistent settings means they're available in the user.config file, which may be judiciously edited as needed. Even better (and definitely recommended), you can provide a user-friendly interface to edit the business rules by binding the persistent settings directly to controls on a Windows form. That way, when users edit the values on the form, the values will automatically be stored in user.config.

Visual Studio 2005's visual designer provides a way to access the user interface layer of your application separately from your code; it automatically turns your interactions in the visual designer into code, which it keeps separate. The business rules for form validation are, of course, intimately tied to the user interface—that is, most of the controls on your form will have one or more specific business rules that you want to validate against. So why not specify the validation business rules in the visual designer where you specify the user interface itself?

The visual designer provides a properties pane for each control on your form. All you need to do is add some business rules as properties. But you can't just add properties to the properties pane, so that is a problem. One easy way around this limitation is to use the Tag property, which is thoughtfully provided as a user-definable property. As there is just one such property per control, you can simply pack the business rules into a package that will fit in the Tag property container. Using this scheme, you can define business rules as you define controls, combining that with persistent settings to externalize the business rules.

To make the connection to the rules, you assign each control to be validated a Tag property value consisting of a series of attributes in the following format:


A more refined solution would be to include an ExtenderProvider control that defines real properties corresponding to the available attributes—leaving the Tag property free for other uses— but I wanted to keep this short and simple.

Table 1 shows the available attributes and their types:

Table 1: Validation Attributes: The table lists the available validation attributes along with their types and a brief description.
Attribute Value Description
maxLen int > 0 field must contain no more than the specified number of characters
minLen int > 0 field must contain at least the specified number of characters
maxVal Float field must contain a number that is no larger than the specified value
minVal Float field must contain a number that is no smaller than the specified value
pattern regular expression field must match the specified regular expression

The first two (minLen and maxLen) let you control the length of the value taken as a string. Similarly, the next two (minVal, maxVal) let you control the range of numerical entries. The final one (pattern) requires a regular expression argument. You can "mix and match" the attribute combinations to suit your needs. Table 2 shows a few common attribute combinations that you may find useful. Note that some constraints that may be expressed with minVal and maxVal may also be expressed with regular expression patterns.

Table 2. Common Validation Attribute Combinations: The table lists some of the more common attribute combintations that you might encounter.
Attribute List Meaning
maxLen=10 Value may be no more than 10 characters.
minVal=0 Value may not be negative.
minVal=0;maxVal=100 Value must be between 0 and 100 inclusive.
minLen=1 Value must be non-empty.
pattern=. Value must be non-empty.
minLen=5;maxLen=5 Value must contain exactly five characters.
pattern=.{5} Value must contain exactly five characters.
pattern=^\S+$ Value may not contain spaces.
pattern=^-?(?:\d*\.?\d+|\d+\.)$ Value must be a number.
pattern=^\d{3}-\d{3}-\d{4}$ Value must be a canonical US phone number.
pattern=^\w[\w\.]*\@\w+\.\w[\w\.]*$ Value must be an e-mail address.

Figure 3. Application Settings: The figure shows the Application Settings entry in the properties pane. You can see that the Tag property contains a pattern-type business rule—a regular expression.
You can enter your business rules in the property pane of each control as you're designing your form in Visual Studio's visual designer. Then, you need to connect that property to an application setting so that it will be externalized when the application is executed. Here are the steps:

First, enter your business rules in the Tag property for a control. Next, find the "Application Settings" entry in the properties pane . If you have the property pane sorted by category, you'll find it under the Data category. Expand "(Application Settings)" to get to the "(PropertyBinding)" entry. Click on the value field to make the property editor ellipsis appear (see Figure 3).

Click on the ellipsis button for "(PropertyBinding)." This will open an Application Settings dialog for the selected control (see Figure 4).

Figure 4. New Application Settings Dialog: Use this dialog to assign property values to individual application settings for controls.
Figure 5. New Application Setting: Assign a name to the new setting.
Find the Tag property, open its drop-down selector, and click "New." You should see the value you entered in the Tag property listed as the default value (see Figure 5). Enter a name for the property. For example, in Figure 5, because this setting is associated with the leftTextBox control in the sample application, I've used the name "leftTextBoxBusinessRules." The Scope may be either Application (a read-only value, global to all users on a single computer, stored in program.exe.config), or User (the setting may be changed within your program and, if so, is stored as an override in a user-specific user.config file the user's Application Data folder).

Click OK to close the New Application Setting dialog and OK again to close the Application Settings dialog. Notice that in the properties pane (see Figure 6) the value of the Tag property is gone, replaced with a little icon, and the Tag property now shows up under the "(Application Settings)" section using the chosen name.

Figure 6. Completed Settings: After assigning a property to application settings, the property (the Tag property in this case) moves under the (ApplicationSettings) item in the Properties dialog, and substitutes a small icon for the original property value.
Figure 7. Missing Value: The Tag property value (the business rule) is missing from the Settings tab of the Project Properties dialog.

Figure 8. Force the Tag Value to Appear: To force the assigned business rule values to appear in the Settings dialog, change the type from System.Object to string.
In theory, that completes the property binding, but in reality, it does not. You still need to perform one more step. Open the "Settings" tab of the Project Properties dialog. Continuing with the leftTextBox control example, you should see the leftTextBoxBusinessRules setting just created, but as Figure 7 shows, the value is missing.

When you assigned the Tag property to application settings, Visual Studio removed the value from the Tag property of the control and—even though it was indicated as the default value for this application setting—it does not show up in the Settings tab of the Project Properties dialog.

This is easy to correct. Simply change the setting Type value from System.Object to string and voilá!—the default value appears (see Figure 8).

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date