Improve Your Custom Outlook Forms

Achieve a perfect match of Outlook item and folder properties

Outlook's ability to display information in a structure that looks like a database's tables and records can be confusing to developers experienced with relational databases because those developers might expect Outlook to behave just like such databases. In fact, Outlook is a "semistructured" database, with no requirement for a tightly defined data structure. Outlook can store different types of items in the same folder; for example, it can display both contacts and distribution lists (DLs) in your Contacts folder. A relational database would require separate folders because these two types of items have different data structures.

This flexibility—and the potential for confusion—is most apparent when you're using custom fields. An Outlook item can contain custom data fields that aren't defined as part of the data structure of the folder that stores the item. (I use the words field and property interchangeably because Outlook uses field in the UI and property in programmers' documentation to mean the same thing.) For example, if you use a form that has a custom property named Project to create new items in a folder, you might find that the Project property doesn't appear on the Field Chooser dialog box for the folder, so you can't show the Project data in a view. You also couldn't use the Find or Restrict method in VBScript code to locate items by using a search for the Project property.

Conversely, an individual item might be missing a custom property that's present in the folder. Let's say you added a ProjectStatus property to a folder. A table view including that property can let users update the ProjectStatus of an item by simply typing a new value directly in the folder view. However, if that item is using a custom form that doesn't include the ProjectStatus property, the item will be one-off. One-off means that the form definition becomes embedded in the item, the size of the item greatly increases, and VBScript code in the form will no longer run under versions of Outlook with the Outlook Email Security Update.

The ideal situation, therefore, is for the custom fields in items in a folder (and the forms used to create those items) to match the custom fields defined on the folder itself. I'll suggest some best practices for achieving this perfect match with form- and folder-based Outlook applications. (If you're new to Outlook forms, you might want to view the half-hour Support WebCast: How to Create Custom Contact Forms in Outlook 2000 at http://support.micro soft.com/servicedesks/webcasts/wc032800/wcblurb032800.asp.)

Creating Custom Fields
The Microsoft article "OL2002: Working with User-defined Fields in Solutions" (http://support.microsoft.com/ default.aspx?scid=kb;en-us;q290656) describes several ways for you to create a new field. The information in this article applies to all versions, not just Outlook 2002. Table 1, page 6, provides a more detailed description of those methods and others. Here are a few notes about the information in Table 1:

How can you tell whether a custom field exists in a folder or an item? The All Fields tab on a form is one of the easiest methods. This tab appears to the user by default only on contact items, but it's always visible on forms displayed in design mode. The User-defined fields in folder list, which Figure 2 shows, displays all the fields defined for the item's parent folder, and the User-defined fields in item list shows the fields explicitly present in the item.

Best Practices for Creating Custom Fields
Given the many different ways to create fields, I've found that the simplest, most reliable method is to create the necessary fields in the folder first, then add them to the custom form so that they'll be present in all items created with that custom form. Use your preferred folder method from Table 1 to create the fields in the folder. When you want to add the properties to the form, use either of the following methods.

Method 1: Drag and drop. With the form in design view, drag fields from the Field Chooser to a custom page on your form. This method works well if you want to create text boxes or check boxes (for Yes or No properties) on the form. If you want to create other controls, such as option buttons or a combo box, use Method 2.

Method 2: Binding the control. Again, with the form in design view, add a control from the Toolbox to your form. Right-click the control, choose Properties, then switch to the Value tab. Click Choose Field, point to the User-defined fields in folder list near the bottom of the fields list, and select the field you want to bind to the control.

If you don't see the list of fields in your folder in this method, you might need to save the item in the target folder first and reopen the item in design mode. Then, Outlook will properly display the fields from your target folder.

Deploying Custom Fields to Other Folders
Outlook provides no straightforward way to copy a set of custom properties from one folder to another. Publishing a custom form to a folder doesn't propagate the custom fields in the form to that folder. The usual technique of clicking File, Folder, Copy Folder Design to copy forms, views, permissions, and other folder-design features doesn't copy custom fields. Therefore, if you want to use a custom form with a folder other than the folder that you originally designed the form to work with, you need a strategy for getting the fields into the new folder. Having the right fields in the folder lets you create appropriate views and ensures that code in your form that uses the Find or Restrict method will run properly with custom properties. Here are three methods for deploying custom fields to other folders.

Method 1: Copy the entire folder. Copying the entire folder can be a good strategy when you know you'll be using the same folder design repeatedly. Remove any test data items from the folder first. You might even archive the folder in a Personal Folders (.pst) file.

One possible problem with this method is duplication of published custom forms, resulting in forms-cache corruption. If a user accesses a form published with the same MessageClass in two different locations, the forms cache on the local system can become corrupt. Therefore, if you use this method, consider publishing the form to the Organization Forms Library rather than to the folder. (That location will also make updating the form easier because you need to make changes only to one central instance of the form.) Alternatively, republish the form to the folder using a new name, then remove the original published form from the new copy of the folder.

Method 2: Create new fields manually. This technique is the brute-force method. Open your custom form so that you can see the All Fields tab, switch to the User-defined fields in this item list, then use one of the folder methods in Table 1 to create a custom field in the folder to match each of the custom properties in the item.

Method 3: Create new fields programmatically. The code in Listing 1 shows how you can add fields to a folder programmatically. The code uses a feature of the UserProperties .Add method to add a new property to an Outlook item and at the same time create the property in the folder. The MakeUserPropsInFolder() subroutine loops through all the custom properties in the currently displayed Outlook item. For each custom property, it creates a matching UserProperty in a dummy item in the target folder. Because the value of the AddToFolderFields parameter (the third parameter) is True, each time the code creates a property in the dummy item, it also creates the property in the folder.

Recipe for Success
If you methodically follow these best practices for creating custom fields, you can be sure that your Outlook form- and folder-based applications will run predictably. By copying an entire folder, you can deploy the design without the need to create custom fields again every time you reuse the application in a new folder.