The Microsoft Developer Network (MSDN) has always carried surprisingly few articles about Microsoft Outlook development capabilities. Until last week, for example, I found little about Outlook 2002—only a scant handful of articles about the new Search and Views objects. I don't know why Outlook gets so little attention from MSDN when it's perhaps the most widely used Microsoft Office application (or at the very least, it's second behind Word). Nevertheless, developers for other environments have a hard time grasping some of Outlook's quirks.
The quirks that stumped me for more weeks that I care to admit were the Explorer and Inspector objects. I was used to working with Word and Excel documents and Access tables, but these objects stymied me. It finally dawned on me that Explorer is the window that displays an Outlook folder, and Inspector is the window that displays an individual Outlook item. Whereas other Office programs associate objects such as the CommandBars that handle toolbars and menus with the overall Application object, Outlook associates its CommandBars with Inspector or Explorer objects.
Outlook is also more like Access than Word or Excel in that it separates the actual data from the onscreen presentation that the user sees. However, Outlook's support for storing different types of data in one folder is very different from the rigid Access requirement that all records in a table use the same data structure.
Too bad I didn't have a resource like MSDN's new Developing Solutions with Microsoft Outlook 2002 when I was learning to develop Outlook applications. In 20 pages, the document provides a quick rundown of the Outlook object model and how to work not only with Explorer and Inspector, but also with key objects for folders and individual Outlook items. Plenty of code samples illustrate the basics.
But for information about deploying Outlook solutions, head straight for the companion Microsoft Outlook 2002 Developer FAQ. In addition to providing details about deployment best practices, the FAQ explains some nuances of designing forms, working with custom fields, and using so-called "one-off" forms, which contain form design information and can exhibit unexpected behavior. The FAQ also makes the point firmly that Visual Basic for Applications (VBA) in Outlook—unlike VBA in applications like Word and Excel, which let you incorporate VBA code into document templates—is a personal development environment.
Most of the information in these articles applies to both Outlook 2002 and Outlook 2000. Even if you're an Exchange administrator, not a programmer, you'll appreciate the FAQ in particular because it's a good guide to some of the design and deployment issues that Outlook-based applications might encounter. To make these articles even better, Microsoft might have added a link to the Office XP Resource Kit's Customizing the Outlook Security Features Administrative Package.