Newcomers to Outlook forms are often surprised that fields that might be visible when the sender is entering data in a custom message form are nowhere to be seen when the recipient opens the message. The three principal causes of this frustrating phenomenon all have relatively straightforward solutions.
If the recipient sees a typical message instead of the custom form, the problem might be that the recipient doesn't have access to the published form that defines the custom form's layout. Inside an Exchange Server organization, you can solve that problem by publishing any custom message form to the Organizational Forms library. If you don't have permission to publish to that central library, then each potential sender and recipient needs to publish the form, with the same message class name, to his or her Personal Forms library.
Is publishing the form to a public folder's forms library a solution? No. Although potential senders can access the form to create new messages, Outlook doesn't know to look in the public folder when a recipient opens the message, so Outlook will use the default form instead of the custom form to show the message.
The second situation occurs when the sender and recipients have access to the published form but recipients still don't see the desired custom layout. In this case, the problem might be that the designer customized only the compose layout. By default, the main page of an Outlook message form consists of separate layouts for composing and reading messages. Outlook doesn't automatically copy fields from the compose layout to the read layout. That's the form designer's job.
A third situation in which a form might appear to be missing fields can occur when the user's interaction with the form makes certain data-entry controls visible or hidden. A typical form might use VBScript code to display a set of data-entry controls when the sender selects a check box on the message form. The sender enters data in the now-visible controls, then sends the message. But when the recipient opens it, the controls are hidden again.
This problem occurs because changes made to the look of an Outlook form at runtime aren't persistent. Outlook has no automatic mechanism for saving the state of the UI when a user sends a message. The only information saved with the message is the data itself (i.e., the values of the built-in Outlook properties and any custom properties associated with the custom form). When the recipient opens the message, the form displays the original layout of the published form.
You might already have guessed the solution: The data-entry controls originally became visible because VBScript code ran when the sender selected the check box. Therefore, you can use VBScript code to make the controls visible again when the recipient opens the item. The key to this technique is that before sending the message, you store information that the code can use to reset the control state when the recipient opens the item.
You don't necessarily need to store information about the control state itself. In most cases, the desired control state depends on some Outlook property, built-in or custom, for which the user has entered a value. Let's return to the example of selecting a check box to reveal an additional control, say a text box that shows the value of the Mileage property. If the sender enters data in that text box, you probably don't need to save information about the state of the check box. The fact that the sender has entered Mileage data indicates that the sender wants to display to the recipient of the message the text box bound to the Mileage property.
If the state of certain controls depends on certain data values, you can use more VBScript behind the form to check those data values and turn controls on or off when the recipient opens the item. Every Outlook item supports an Open event that fires when the user opens the item in its own window. By using the Open event handler to check the values of various properties in the item, the code can determine how to display different controls-–make them visible, hide them, perhaps even change their text or background colors to highlight key information. As long as the recipient has access to the published custom form, there's no reason that the message displayed with that custom form can't look exactly as the sender intended it to.
