OutlookCode.com articles

Form region: Categories text box

Wed, 01 Oct 2008 19:08:13 GMT

Outlook 2007 includes a new feature called form regions to extend the user interface for individual items with custom pages and controls embedded in both the reading pane and standard pages. Most form region applications use an add-in to control the behavior of a form region and its controls, but it is also possible to create simple form regions to add data entry and viewing controls.

For example, Outlook 2007's built-in Categories control does not allow the user to type in a list of categories. The MessageCat sample form region can solve that problem by adding a region at the bottom of each open, read message where the user can type in a list of categories.

Installation

To install the MessageCat form region, follow these steps:

Download the messagecat.zip file and then expand it into its three individual files.
Copy the messagecat.xml and messagecat.ofs files into a separate folder, for example, C:\Data\Regions.
If you use a folder other than C:\Data\Regions for step #2, open the messagecat.reg file in Notepad or another text editor. It should look like this:

Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\FormRegions\IPM.Note] "MessageCat"="c:\\data\\regions\\messagecat.xml"

Edit the path for the MessageCat value (the last line) so that it matches the path you used in step #2.
Run the messagecat.reg file to add the FormRegions and IPM.Note keys to the registry, if they are not already present, and to add the MessageCat value.
Restart Outlook.

Usage

To use the form region, open any received message. You should see the MessageCat region at the bottom of the window:

The Categories box will show the existing categories on the item, and you can type in it or delete categories directly from it. Save the message before closing it, or close it and answer Yes to the prompt to save changes.

Enhancements

If you want the region to appear on messages being composed as well as those being read, you can edit the messagecat.xml file to change the value for the <showInspectorCompose> element from false to true. DO NOT attempt to modify this .xml file to allow the region to be used in the reading pane. Items in the reading pane are read-only; therefore, you cannot use a form region to type in new values for the Categories property for an item visible in the reading pane.

To see how the region is constructed or to add other controls to the region, open a message form in design mode, and then choose Form Region | Open Form Region to open the messagecat.ops file. Make any modifications you want, then choose Form Region | Save Form Region to save your changes.

To automatically Bcc all outgoing messages

Tue, 20 May 2008 15:10:45 GMT

Outlook has a rule to automatically Cc another person on outgoing messages, but no equivalent for Bcc. This page offers two code samples for adding such an automatic Bcc. Both use the Application.ItemSend event, which fires whenever a user sends a message or other item.

Method #1 (Basic)

This version is suitable for Outlook 2003 or later. It uses Outlook objects exclusively and includes error handling to avoid problems with an invalid Bcc address. Place this VBA code in the built-in ThisOutlookSession module:

Private Sub Application_ItemSend(ByVal Item As Object, _ Cancel As Boolean) Dim objRecip As Recipient Dim strMsg As String Dim res As Integer Dim strBcc As String On Error Resume Next ' #### USER OPTIONS #### ' address for Bcc -- must be SMTP address or resolvable ' to a name in the address book strBcc = "someone@somewhere.dom" Set objRecip = Item.Recipients.Add(strBcc) objRecip.Type = olBCC If Not objRecip.Resolve Then strMsg = "Could not resolve the Bcc recipient. " & _ "Do you want still to send the message?" res = MsgBox(strMsg, vbYesNo + vbDefaultButton1, _ "Could Not Resolve Bcc Recipient") If res = vbNo Then Cancel = True End If End If Set objRecip = Nothing End Sub

Make sure you substitute the right e-mail address for "someone@somewhere.dom."

The reason that this method is not suitable for versions earlier than Outlook 2003 is because it will trigger an address book security prompt due to the use of Recipients.Add. You could avoid security prompts by simply setting the Item.Bcc property to the desired address, but that has two problems. First, it would wipe out any Bcc recipients that the user might have already added. Also, in some Outlook configurations, setting Bcc without trying to resolve the address results in an unresolved address, even if you use a proper SMTP address; you'll get an error, and Outlook won't send the message.

Method #2 (Redemption)

This version uses the same basic technique as Method #1, only with the third-party Outlook Redemption library to avoid security prompts in versions before Outlook 2003 and, if the recipient cannot be resolved, to display to the user the name resolution dialog.

Private Sub Application_ItemSend(ByVal Item As Object, _ Cancel As Boolean) ' Requires a reference to ' the SafeOutlook library (Redemption.dll) Dim objMe As Redemption.SafeRecipient Dim sMail As Redemption.SafeMailItem On Error Resume Next Set sMail = CreateObject("Redemption.SafeMailItem") Item.Save sMail.Item = Item Set objMe = sMail.Recipients.Add("myaddress@mydomain.dom") objMe.Type = olBCC If Not objMe.Resolve(True) Then Cancel = True End If Set objMe = Nothing Set sMail = Nothing End Sub

Make sure you substitute the right e-mail address for "myaddress@mydomain.dom."

Add-in threading issue causes Outlook to crash or hang

Thu, 22 Nov 2007 14:11:42 GMT

If you have written an Outlook add-in with Visual Basic 6.0 and you are getting new and unexpected reports of it crashing, you might want to ask the user whether the Apple ITunes add-in is also installed. According to Outlook MVP Ken Slovak, the ITunes add-in, which synchronizes the Outlook calendar with an IPod, can cause Outlook 2007 to crash and Outlook 2003 to hang in a way that makes it look like another VB6 add-in is responsible, because of a threading issue.

UPDATE: As of 18 Jan 2008, Apple has released a new version of the iTunes add-in that does not produce this behavior.

The Microsoft support engineer whom Ken has been working with explained that Outlook was designed with the assumption that all calls to the Outlook object model are on thread 0. Some other often used DLLs also make that assumption, including the VB6 runtime (MSVBVM60.DLL), which is used in many of the Outlook add-ins currently available.

The problem apparently occurs because the Apple add-in sets up a new thread using a named pipe to do the calendar synching but neglects to marshal the thread back to thread 0 for any calls to the Outlook object model. Instead, it calls into the object model instead on thread 7. This lack of a proxying back to thread 0 then sets Outlook to call into MSVBVM60 to pass along any events that have fired due to the object model access (for example the ItemLoad event available only in Outlook 2007, which fires on every object model access to any Outlook item). This then crashes Outlook due to the threading. The stack is read by Watson and whatever is at the bottom of the stack gets blamed for the crash, usually MSVBVM60 but also Kernel32 on Vista. The next time Outlooks starts up, whichever addin was listed lowest in the stack is then blamed for the crash.

If no VB6 addin is running, Outlook doesn't immediately crash. Instead, it becomes unstable and might crash at any later time, or it might just get hung in a deadlock between threads, something that won't happen if all calls to the object model are called in thread 0.

According to Ken, there is no possible defensive programming that an add-in developer can do to prevent another add-in from causing this problem. The problem add-in must change its code to prevent the problem from occurring. Microsoft is in touch with Apple about the problem with the ITunes add-in. However, any other vendor whose add-in takes the same approach to threading will cause the same problem, which means that this is a vendor-by-vendor problem that will have to be addressed each time a problem add-in is discovered.

Using the Outlook View Control

Thu, 08 Nov 2007 22:54:27 GMT

The Outlook View Control (OVC) is an ActiveX control that automatically installs with Outlook. It can display the contents of an Outlook folder in an Outlook custom form, folder home page, or add-in. It also has some limited usefulness for displaying Outlook data in a web page or other external application.

Usage

Basic implementation information is available at:

Microsoft Outlook View Control Reference (documentation) - written for Outlook 2002, but also applies to later versions

You must set the Folder parameter for the OVC or it will appear blank. The Folder parameter is language-dependent. It need the name of the folder or path as seen in the user's Folder List (and returned by the FolderPath property).

If you are using the OVC in a web page or other non-Outlook application, omit the View parameter (e.g. <param name="View" value="By Category">) in the initial settings for the control. If you set the View this way, even to value="", more often than not it will cause the control to default to the user's Inbox rather than showing the folder you want. See Outlook View Control View Issue Demo for a demonstration of this issue.

To show only certain items in the OVC, use either the Restriction property, which takes the same query syntax as the Items.Find and Items.Restrict methods, or the Filter property, which takes a DASL query.

Limitations

The OVC can show only one folder at a time. It cannot duplicate the multi-folder list of items that Outlook shows on the Activities tab of a contact form.

Access to the OutlookApplication property, which returns an Outlook.Application object, is blocked unless the OVC is running in an Outlook context (such as a custom form or folder home page).

Known Issues

Don't use DeferUpdate if you're also planning to apply a Restriction. See the discussion at OVC Restriction Only Functions After Filter.

The OVC cannot be used as a control on an Access 2007 user form.

Also see:

Using the Microsoft Office Spreadsheet Control on an Outlook Form

Thu, 08 Nov 2007 21:39:14 GMT

If you need to have users enter several lines of data and do calculations on it -- as in an order form, for example -- consider using the Microsoft Office Spreadsheet control on your Outlook form. This control works just like an Excel spreadsheet and can be manipulated programmatically from VBScript code on the form.

Basics

The spreadsheet control requires that Microsoft Excel be installed. The control should be installed automatically with the Professional edition of Office 2003 if you install Excel. We have not checked on its availability in other Office 2003 packages.

It is not available in Office 2007. However, if you installed Office 2003 first and then upgraded to Office 2007, the spreadsheet control may be work OK.

To add the spreadsheet control to the Outlook custom form control toolbox:

Open any Outlook form in design mode, and click the toolbox button on the toolbar.
Right-click the blank space on the toolbox, and choose Additional Controls.
If you don't see Additional Controls, open the Outlook VBA environment, create a new form, bring up its toolbox, then repeat Step 2.
From the Available Controls list, choose Microsoft Office Spreadsheet.
The control should now appear in your toolbox.

To add the spreadsheet control to a form:

Select the control in the toolbox.
On the form, drag the mouse to lay out a rectangle where you want the form to appear.

Customizing the Control

As with most controls, you can resize the spreadsheet.

You can also copy cells from an existing Excel worksheet into the spreadsheet control.

However, some of the most important customizations take place on the property toolbox for this control. To display the property toolbox:

Click twice (not a double-click, but two separate clicks) on the control to select it with a dark border.
Click the Property Toolbox button .
Make your choices on the various sections of the property toolbox. For example, under the Show/Hide section, you might want to turn off the title bar, toolbar, and column and row headers. Under Protection, you might want to disable the user's ability to access the property tool box when the form is running.
To format cells, select the cells, then make your choices on the Formatting section of the property toolbox.

Another way to customize the toolbox is by writing code in the form events using standard Excel Spreadsheet properties and methods. This code fragment, for example, might be included in the Item_Open event.

Set oPage = Item.GetInspector.ModifiedFormPages("Message") Set Spreadsheet1 = oPage.Controls("Spreadsheet1") Spreadsheet1.ViewableRange = "A1:F12" For r = 2 to 11 ' row number Spreadsheet1.ActiveSheet.Cells(r, 6).Formula = _ "=C" & r & "*E" & r Next Set pt = Spreadsheet1.ActiveSheet.Protection Spreadsheet1.Columns(6).Locked = True For I = 1 To 5 Spreadsheet1.Columns(I).Locked = False Next pt.AllowDeletingColumns = False pt.AllowDeletingRows = False pt.AllowFiltering = False pt.AllowInsertingColumns = False pt.AllowInsertingRows = False pt.AllowSizingAllColumns = False pt.AllowSizingAllRows = False pt.AllowSorting = False pt.Enabled = True

The above code makes the following changes on the spreadsheet:

Limits the range of cells that users can scroll across, so that they always stay in the area the developer wants
Adds a formula to column F to multiply the values in columns C and E
Sets up protection on the spreadsheet so that the user cannot type into the cells in column F, cannot resize columns, etc.

Handling Data

You cannot bind the spreadsheet control to an Outlook property. This means that Outlook will not automatically save the data that users enter into the control. Therefore, you must provide a way to save the data and restore it when the user reopens the form. You can use the HTMLData property for this. The following code is for a form where the Message or Notes control (which displays the Body property) has been removed. It saves the data to the item's Body property (which is not visible to the user because there is no control to display it) when the user saves the form and restores it when the user opens the form:

Dim XLSheet Function Item_Open() Set oPage = Item.GetInspector.ModifiedFormPages("Message") Set XLSheet = oPage.Controls("Spreadsheet1") XLSheet.HTMLData = Item.Body Item.Subject = Trim(Item.Subject & " ") 'Dirty the form End Function Function Item_Write() Item.Body = XLSheet.HTMLData End Function

Setting Item.Subject equal to itself ensures that users will get a "Save changes?" prompt when they close the form. (Since the spreadsheet control is not bound to a property, changing the data in the spreadsheet does not "dirty" the form.)

If you need to use the Body property for an actual message, then you'll need to use some other property to store the spreadsheet data. All Outlook items contain built-in BillingInformation and Mileage properties, or you can add your own custom text property. However, the amount of data that can be stored in standard and custom properties, other than the item body and attachments, is limited to 32kb.

Limitations

The spreadsheet control does not fire a Click event (or any other event) when used on an Outlook form.

You cannot place another control in front of the spreadsheet control on an Outlook form.

Troubleshooting Outlook VBA

Wed, 07 Nov 2007 22:07:17 GMT

Sometimes Outlook VBA won't run. Likely causes include macro security settings, missing or disabled components, or external programs starting Outlook and holding it open. This page aims to present the most common causes and solutions.

Macro Security

The most common cause of VBA code not running is the macro security setting. The default setting does not allow any Outlook VBA code to run. For instructions on how to change the setting and test whether VBA is working, see:

Outlook VBA Basics

I recommend that most people use Medium in Outlook 2003 or Warnings for all macros in Outlook 2007, because that ensures that you'll get a prompt, which will let you know that Outlook VBA has loaded. You can use the next higher macro security setting if you sign your VBA project with the Selfcert.exe tool that comes with Office; see Writing VBA Code for Microsoft Outlook for details.

If you choose Very High (available in Outlook 2003 only) Outlook VBA macros will not run, since Outlook 2003 has no default "trusted location."

These articles from the Office Resource Kit explain macro security in detail:

Overview of security in the 2007 Office system
Understanding Macro Security Levels in Office (Outlook 2003)
Change the Outlook security level for macro virus protection (Outlook 2003)

Outlook Held Open

If the macro security dialog doesn't open or if Alt+F11 does not open the VBA window, you may have a different problem: VBA itself isn't loading. One possible cause is that another program is starting Outlook without any user interface and, when the user starts Outlook's UI, most COM add-ins -- including the VBA environment -- won't start up.

To troubleshoot, shut down Outlook and wait a few minutes. Use Ctrl+Alt+Delete to display the Task Manager and make sure that Outlook.exe is no longer running. If it is, you almost certainly have a program holding Outlook open; use the Task Manager to stop Outlook. Then quit or disable any anti-virus, anti-spam, fax, or PDA synchronization utilities. (You may want to disconnect from the Internet during this phase of the troubleshooting.) Restart Outlook and try to get into VBA. If it works, then quit Outlook and restart one of the utilities you turned off. Restart Outlook to see if VBA runs OK. Repeat with the other utilities. If you find one that makes it impossible to start VBA, you may need to start Outlook before you run that utility. Make sure that such a utility is not set to start when Windows starts, so you can start it after you run Outlook.

VBA Not Trusted

Outlook supports, but does not normally set a DontTrustInstalledFiles registry value that controls whether COM add-ins are trusted. VBA itself is a COM add-in, so if DontTrustInstalledFiles is set to 1 and macro security is set to High, no COM add-ins run, including VBA.

In Outlook 2003, you can also control this option with the Tools | Macro | Security dialog, on the Trusted Publishers tab, using the Trust all installed add-ins and templates check box.

Other Possible Causes

VBA is part of a default Outlook installation, but in a custom installation, it can be omitted or disabled. Try rerunning Office or Outlook setup and, under Office Shared Features, make sure that the VBA and Visual Basic Help components are installed.

If you still can't find the cause, try creating a new Windows user profile. That will provide a clue as to whether the issue is with the installation or with the particular user's settings.

Outlook Custom Forms Security Issues

Wed, 07 Nov 2007 21:39:42 GMT

Custom Outlook forms are subject to several layers of security that determine whether VBScript code behind the form can run and whether ActiveX controls (beyond those included with Outlook) are blocked.

In most cases, if VBScript code does run, it will not be subject to "object model guard" security prompts, as long as all Outlook objects are derived from the intrinsic Application and Item objects that custom form VBScript code supports. For information on these security prompts, see:

Microsoft Outlook "Object Model Guard" Security Issues for Developers

This page covers strategies for dealing with other security issues related to Outlook custom forms in current versions.

Forms in Other Mailboxes

By default, items created with custom forms do not run code when the user opens them from a shared mailbox. You can change the setting by choosing Tools | Options | Other | Advanced Options and checking the box for Allow script in shared folders. You'll see that there is also an option for Allow script in public folders. In Outlook 2007, these settings are in the Tools | Trust Center dialog, under E-mail Security.

The corresponding registry values for Outlook 2003 are in the HKCU\Software\Microsoft\Office\11.0\Outlook\Security key -- SharedFolderScript and PublicFolderScript, both DWORD values. For Outlook 2007, replace 11.0 with 12.0.

Note that these settings affect both script in custom forms for items in public folders and script in folder home pages for such folders.

For more information, see:

Explanation of the Allow Script Check Boxes in Outlook 2003

One-off forms

Code will not run on items created from unpublished or one-off forms. Also, some ActiveX controls will be blocked, as described below. The one-off issue affects:

Items created with saved .oft file templates
Items created with forms that were published with the Send form definition with item box on the form's (Properties) page checked
Items created with properly published forms that later one-offed because of code behind the form or the additional of a custom property

To ensure that a form does not one-off:

Make sure the Send form definition with item box on the (Properties) tab of the form is not checked. When you publish a message form in Outlook 2003, Outlook will suggest that you may want to check the Send form definition with item box to ensure that the recipient will have the form, especially if you're sending to someone via the Internet. In the current Outlook security environment, this suggestion is obsolete and misleading. Ignore it unless your form has no code behind it.
For in-house corporate use with Exchange Server, publish a message form to the Organizational Forms library. Publish other types of forms to Organizational Forms or a public folder's forms library, as appropriate for your application.
On a custom message form, on the (Actions) tab, set the custom form for the Forward action to the same class as the original form. In other words, publish the form, then go to the (Actions) tab, set the Forward action's form to the same class, and publish a second time.

Many things can cause one-off forms. If you are still getting one-offs after publishing as described above, see Saving and Publishing Microsoft Outlook Custom Forms for possible causes and cures.

Blocked ActiveX Controls

If a form is a one-off, only the basic form controls (text box, combo box, etc.), message body control, recipient control, and Outlook View Control will load. If a blocked control is present on a one-off form, when the user attempts to display the page showing that control, they'll see this error message:

To help prevent malicious code from running, one or more objects in this form were not loaded. For more information, contact your administrator.

The ideal solution for this issue is to avoid one-off forms completely. If you must use a one-off and you are using Outlook 2003, you can use a registry entry or policy to control the behavior. (This option is not availble in Outlook 2002 SP3). To use a registry entry, add a DWORD value named AllowActiveXOneOffForms to the HKCU\Software\Microsoft\Office\11.0\Outlook\Security value and set it to one of these values:\

0 Load only the frm20.dll controls, the Outlook View Control, Outlook Recipient Control, and the docsite (message body) control

1 Allow only controls marked as "safe for initialization" to load

2 Allow all ActiveX controls to load

Note that published forms are not affected by this issue. If you're seeing the error message above, that's an almost certain indication that the form is now a one-off.

Using Outlook custom forms over the Internet - Not!

Wed, 07 Nov 2007 20:46:57 GMT

In short, don't do it. Even thinking about trying to use custom Outlook message forms to send items over the Internet is probably a waste of your valuable time. The prerequisites for getting custom forms to work over the Internet in current Outlook versions are so stringent that your chances of success are very, very slim.

If You Insist

If you insist, despite the warning, these are the prerequisites that must be met:

All users must be using Outlook.
All users must have access to the published form definition. As a practical matter, that means the form must be published to each user's Personal Forms library or, in an Exchange environment, to the Organizational forms library, with each published instance of the form using the same message class, such as IPM.Note.MyForm. Furthermore, the Send form definition with item box on the (Properties) page of the form must not be checked.
All the mail servers involved must allow rich-text content to pass. In some Exchange environments, outgoing RTF content is stripped by the server.

If all these conditions are not met, the other user will see your custom form item in the standard Outlook form, not your custom form, and will have no access to any custom properties or VBScript code behind the form.

It can get even worse: If you create a message using a custom form and send it to a non-Outlook recipient, that person may get an annoying Winmail.dat file as part of the message and wonder why they can't open it. At worst, they won't even be able to see any attachments that you included with the message.

What about Templates?

The above caveats apply to any Outlook form that is designed to display custom fields or run code for the person on the receiving end. Those features require a published custom form. You do not, however, need a published custom form if you just want to use some boilerplate text to make it easy to send certain messages on a regular basis. In such scenarios, do not publish a custom message form. Instead, create your boilerplate message, then save it to the file system as an Outlook template .oft file. To create a new message from the .oft template, just double-click it.

If you are using Outlook 2003 with Word as your email editor, you will need to go to Tools | Options | Message Format and turn off Word as the email editor before you create the boilerplate message. If you don't do that first, you will not be able to save it as an .oft file.

A Marginal Workaround

As a workaround for the problems related to using a custom message form over the Internet, I used to recommend using the Item_Send event handler on a custom message form to create and send a completely new message with the standard form, inserting data from custom properties on the original custom form message into the Body or HTMLBody property. However, because the Item.Close method is broken in versions of Outlook 2007 before SP1 and in current versions of Outlook 2003 (unless you get the right hotfix from Microsoft), you probably would have to leave the original custom message form open, which would confuse many users. Therefore, I cannot wholeheartedly recommend this solution.

Routed Message Form for Microsoft Outlook

Wed, 07 Nov 2007 14:37:51 GMT

The Routed Message Form by Jay Harlow is a Microsoft Outlook custom message form that can be used to send a message sequentially to a list of Outlook recipients. It uses a custom RouteTo text field to keep track of the recipients while the form is being routed to the next person in the To box. This form demonstrates several basic Outlook form design techniques:

Custom actions, defined on the (Actions) page in design mode, firing code in the Item_CustomAction event handler
Code for the Send event that fires when the user sends a message based on this form

Prerequisite

To use this form, you must be able to publish it to the Organizational Forms library on the in-house Exchange Server. It cannot be used to collect data from recipients outside your organization.

Setup

Download the Routemsg.zip file (5kb), then extract the Routemsg.oft file that it contains.
In Outlook, choose Tools | Forms | Choose Form.
At the top of the Choose Form dialog, select User Templates in File System.
Navigate to the folder that you used in Step 1 to extract the Routemsg.oft file.
Click Open.
Publish the form to the Organization Forms library so that every one in your organization can use it. Do NOT check the Send form definition with item box on the (Properties) page of the form.

Usage

To create a routed message:

Choose Tools | Forms | Choose Form, then select either Organizational Forms, select Routed Message, and click Open.
In the To box, enter the addresses you want the form routed to, in the order you want them to receive the message. Enter your own address last if you want to receive the message after everybody else has responded.
Click Send.

When a recipient receives the message, he/she sees the message is addressed to him/her only. There is a Route To box containing the list of names who have not yet received the message. When the recipient is done with the message, he/she clicks Route to send it to the next person.

The last recipient does not see any names in the Route To box.

How It Works

The VBScript attached to this form has two routines:

Item_Send - deletes all of the recipients except the first one, after saving the display names of the recipients in the RouteTo custom text field.
Item_CustomAction - looks for the Route action, which is defined on the (Actions) page, to send the message to the next recipient. When the last recipient uses the Route action, nothing happens. Jay did not not implement any "Return to originator" feature, but the originator could simple add himself as the last person in the To field when composing a new Routed Message.

Using these two routines, one should be able to use this form to build more complex routing forms. For example, if you saved the name of the originator (Application.Session.CurrentUser.Name) in another custom text field, you could add code in the Item_Forward or Item_Send event hander that would send the Originator an e-mail whenever the message was forwarded.

How the Outlook forms cache works

Tue, 06 Nov 2007 21:54:56 GMT

When a user opens an item, Outlook looks at the value of the item's MessageClass property to determine whether the item should be displayed with a standard form, a custom form, or (beginning in Outlook 2007), a form region. If the item requires a published custom form, Outlook stores a copy of the form on your local hard disk. The next time you need to use the form, Outlook checks this forms cache. If the form is in the cache, Outlook goes to the form's original location to check the form's Modified timestamp. If a user has modified the form since Outlook cached it, Outlook opens the form from its original location and updates the cache with the modified version. If no one has modified the form since Outlook cached it, Outlook loads the form from the cache, which is usually much faster than opening it from the original location.

If the required form isn't in the cache, Outlook looks in other locations, in this order:

The forms library for the currently displayed folder
Personal Forms library - in the user's default information store
Organization Forms library - on the Exchange server

The location of the forms cache depends on the operating system, where %username% is the environment variable containing the user's login name:

Windows Vista - C:\Users\%username%\AppData\Local\Microsoft\FORMS
Windows XP - C:\Documents and Settings\%username\Local Settings\Application Data\Microsoft\FORMS

The cache contains a Frmcache.dat file, which maintains a summary of cached forms and pointers to the cached files, plus a subfolder for each cached form.

Error Messages

Error messages such as

The form required to view this message cannot be displayed
Can't create item

often signal corruption related to a custom form-either in the form itself or in the data file on the client that stores forms cache information. Exactly what causes forms cache corruption is not known.

If corruption occurs frequently and clearing the forms cache (see below) does not solve the problem, you can use the ForceFormReload registry entry to force Outlook to reload a form from the original published version when Outlook can't load the form from the cache. See:

Clearing the Forms Cache

The first step in troubleshooting is to use the command in Outlook to clear the cache using the Manage Forms dialog (Tools | Options | Other | Advanced Options | Custom Forms, then click Manage Forms).

If that does not resolve the problem, shut down Outlook and delete the entire contents of the FORMS folder (for locations, see above).

Notes

The order Outlook uses to look for a form explains a common problem. Suppose a user publishes a new form in the Personal Forms library. Later, the user makes changes to the form and publishes the revised form under the same name but in a different library-Organization Forms. When the user opens an item that uses the custom form for the first time, Outlook loads the version in the Personal Forms Library because Outlook checks that location first, but that version won't include the revisions on the version the user saved in the Organization Forms Library.

The stumbling block is the copy in the Personal Forms library. The solution is to delete that copy by using the Manage Forms dialog (Tools | Options | Other | Advanced Options | Custom Forms, then click Manage Forms). After you delete that copy, the Organization Forms copy usually loads fine. If it doesn't, make sure that you're incrementing the version number on the form's (Properties) page. You can also try using the form to create a new item. When opening a previously created item doesn't load the updated form into the cache, creating a new item sometimes does the job.

0		Load only the frm20.dll controls, the Outlook View Control, Outlook Recipient Control, and the docsite (message body) control
1		Allow only controls marked as "safe for initialization" to load
2		Allow all ActiveX controls to load