Controlling the Data That Users Enter in Custom Outlook Forms

One of the challenges that face designers of custom Outlook forms is how to make the data that users enter look exactly right. Native Outlook techniques don't cover all situations, but they address many common, simple data-entry needs. You'll need to have your form in design mode before implementing the techniques I describe here.

Frequently, form designers want to limit the number of characters that users can type into a particular text box on a form. To do so, right-click the text box, choose Advanced Properties, and enter the desired limit as the value for the MaxLength property. When users try to type more characters than the limit, they won't receive an error message--they just won't be able to type further.

If you've used Microsoft Access forms, you might be familiar with Access's Input Mask Wizard, which lets you limit the number of characters that users can type and force them to type characters in a particular formatted sequence. Unfortunately, Outlook doesn't include any capability for using an input mask to handle telephone or Social Security numbers or other tightly formatted data. Both Microsoft and third-party software vendors provide input-mask controls that you can use on an Outlook form. However, if you use one of these, you must provide a setup program that properly registers the control on each user's machine.

Outlook will try to properly reformat a telephone number in one of its built-in phone fields automatically. However, this functionality disappears in Outlook 2000 if you customize the first page of the contact form. The Microsoft article "OL2000: How to Use the Intellisense Feature in Outlook to Format Custom Phone Number Fields" ( http://support.microsoft.com/?kbid=266267 ) suggests a workaround using some VBScript code behind the form.

Another simple technique built into Outlook is to mark a certain property as required. To access this and more-complex validation options, right-click the control that displays the property, then choose Properties and go to the Validation tab. The simplest validation choice--the "A value is required for this field" check box--might look easy to use, but it's actually a bad choice. If you use it and the user doesn't enter data in the required field, the user receives only a cryptic "A field on this form requires a value" prompt that gives no hint as to which field needs data.

If you want to require entry in a text field, a better solution is to enter this simple formula in the Validation Formula box:

[TextFieldName] ""

where TextFieldName is the actual name of the built-in or custom text property that you want to validate. You can click Edit next to the Validation Formula box and choose the field from the Fields list. Using a validation formula lets you create a custom error message in the "Display this message if the validation fails" box, telling the user which field needs a value and any specific requirements for that value.

Both the simple validation of a required property and formula-based validation can work even with built-in properties that appear on a page that you can't customize, such as the Details page on a contact form. The trick is that the validation information is actually stored with the property, not as part of the form layout. Knowing that, you can create a new custom page on your form, drag a built-in property from the Field Chooser, then use the Validation tab of the control for that property to set up the validation. Before you publish the form, you can hide that page with the Form, Display This Page toggle command.

Validation has one big potential pitfall: Because Outlooks stores the validation information with the property, the validation setting always applies regardless of whether the user can actually enter data for that field on the form. In particular, it applies even if you remove the control from the form. What's worse, as I mentioned above, if you use the simple required field validation technique, the error message doesn't actually tell you which property's data is missing. Therefore, before removing a control from an Outlook form, you should always check the Value tab on the control's Properties dialog box and clear any validation options.

If you want to build a more complex validation formula, perhaps involving multiple fields, my Commentary "More About Outlook Formulas," http://www.winnetmag.com , InstantDoc ID 21002, should be helpful. I'd love to hear about any validation challenges that you've faced and the solutions you devised.