David Shank
November 4, 1999
I've been a bit remiss around the office lately, particularly when it comes to answering my mail. I have received a lot of great feedback and many good questions over the past few months. I've tried to reply to each specific question, but it occurred to me that the information might be of interest to everyone.
As I rummaged through the mailbag, I noticed that questions could be grouped into common topics. One of those had to do, in one way or another, with Microsoft Outlook®. Since working with Outlook is the theme on the Office Developer site this month, I thought it would be a good time to address those questions.
I liked your discussion of command bars, but your sample code does not work when I try to use it in Outlook. What am I doing wrong?
Don't worry. The problem isn't you; it's me. Last month, I talked about working with command bars and used code examples that illustrated the Commandbars collection as a child of the Application object. Well, that is where you will typically find command bars -- except in Outlook.
Command bars in Outlook are children of Explorer or Inspector objects. Simple enough, but what in the heck are Explorer or Inspector objects? The Explorer object represents what you would recognize as the Outlook user interface. It is a window that displays the contents of a folder. For example, when you are looking at e-mail in your inbox, you are working in an Explorer object. A window that contains a specific Outlook item, such as a mail message or a contact, is an Outlook Inspector object. You can use the ActiveExplorer and ActiveInspector methods of the Application object to return a programmatic reference to the Explorer or Inspector object that is currently displayed.
To add, remove, or manipulate command bars in Outlook, start with a reference to the Explorer or Inspector object that contains the command bar you want to use, and then use the object's CommandBars property to return a reference to the object's CommandBars collection. For example, the following code shows how to return a reference to the CommandBars collection for the currently active Explorer object and Inspector object:
‘ Set a reference to the CommandBars collection and
‘ to the Standard command bar.
Dim cbrExplorerBars As CommandBars
Dim cbrStandard As CommandBar
Set cbrExplorerBars = ActiveExplorer.CommandBars
Set cbrStandard = cbrExplorerBars("Standard")
‘ Set a reference to the Standard command bar associated
‘ with the active Inspector object.
Dim cbrInspector As CommandBar
Set cbrInspector = ActiveInspector.CommandBars("Standard")Once you have your reference to the CommandBars collection or to a particular CommandBar object, you work with the object in the same way as in any other Office application.
I have worked with Microsoft Visual Basic® for Applications code in Office documents for a long time, and I think it's great that Visual Basic for Applications is finally part of Outlook. But there is no such thing as an Outlook document, so I am wondering where Outlook Visual Basic for Applications code is stored?
While other Office applications support a separate Visual Basic for Applications project for each document, Outlook supports only a single Visual Basic for Applications project that is associated with a particular user and a running instance of the application. In Outlook, Visual Basic for Applications code is associated only with the application itself. The single Outlook Visual Basic for Applications project is stored in a file named VbaProject.OTM in the following locations:
I have written script to respond to events for Outlook items, like a mail message, but how do I hook into events at the application level?
There are two classes of events in Outlook, and you work with each class differently. The first class represents item-level events that are associated with a particular Outlook item. For example, an Outlook MailItem object has events such as Open, Close, Forward, and Send (you use Visual Basic Scripting Edition [VBScript] code within the item itself to handle these item-level events).
The second class of events supported in Outlook represents application-level events. Because these events are associated with the application itself, or with top-level objects within the application -- such as folders or the Outlook Bar -- you can use Visual Basic for Applications code to handle them.
In Outlook, because you use Visual Basic for Applications to work with the application, the Visual Basic for Applications project contains a class module called ThisOutlookSession, which is pre-bound to the Outlook Application object. As a result, all application-level events are available to you in the Visual Basic Editor's Procedures drop-down list when you click the Application object in the Object drop-down list.
There are six events associated with the Application object that you can use to run custom Visual Basic for Applications procedures. These events are: ItemSend, NewMail, OptionsPagesAdd, Quit, Reminder, and Startup. As an example, you could use the Startup event to call custom procedures to customize the Outlook workspace or to create or display custom command bars or command bar controls. You could use the NewMail event procedure to call custom procedures that implement your own rules for handling incoming mail. These events are somewhat self-explanatory, and you can get complete documentation for each event by searching the Microsoft Outlook Visual Basic Reference Help index using the name of the event.
Working with the event procedures exposed by other Outlook objects requires a few more steps than are required when you are working with Application object events. First, you must declare an object variable by using the WithEvents keyword in the ThisOutlookSession module (or in another class module) for each object with which you want to work. Second, you must add the Visual Basic for Applications code to the event procedure that you want to run when the event occurs. Finally, you must initialize the object variables that you have created.
For example, the following Visual Basic for Applications code illustrates how to create an object variable that represents the Outlook Bar in the ThisOutlookSession module:
Dim WithEvents obpOutlookBar As Outlook.OutlookBarPaneOnce you declare an object variable using the WithEvents keyword, the variable name appears in the Object drop-down list in the class module's Code window. When you select this variable from the Object list, you can select the object's available event procedures by using the Procedure drop-down list. For example, the OutlookBarPane object shown earlier exposes the BeforeGroupSwitch and BeforeNavigate events.
Private Sub opbOutlookBar_BeforeNavigate(ByVal Shortcut _
As OutlookBarShortcut, Cancel As Boolean)
If Shortcut.Name <> "Inbox" Then
Msgbox "Sorry, you only have permission " _
& "to access the Inbox."
Cancel = True
End If
End SubNow you need to initialize the object variable. You can do this in two places: in the Application object's Startup event procedure, so that the variable is always available, or in a custom procedure you create for the purpose of initializing object variables. The following code shows how to initialize the object variable by using the Startup event procedure:
Private Sub Application_Startup()
Set opbOutlookBar = Application._
ActiveExplorer.Panes("OutlookBar")
End SubTo determine how to instantiate an object variable, search the Microsoft Outlook Visual Basic Reference Help index for the name of the object you want to work with. For example, the Help topic for the OutlookBarPane object shows that the object is a member of the Panes collection and that you use the string "OutlookBar" to identify the object within the collection.
You can get more information about the objects, methods, and properties in the Outlook object model by using Microsoft Outlook Visual Basic Reference Help in the C:\Program Files\Microsoft Office\Office\1033\Vbaoutl9.chm file.
I understand the role that folders play in Outlook, but I don’t know what a Team Folder is. Can you tell me about Team Folders in Outlook?
Team Folders are a new technology you can use in Outlook 2000 and Exchange Server version 5.5 to easily create workgroup collaboration solutions. Now, if you are like me, whenever you see terms such as "workgroup collaboration solutions," your eyes glaze over (I promise I won't use that term again). The point I want to make is that Team Folders are a cool way to make it easier for people to work together. You can use Team Folders to create a single place to access shared documents, set up meetings, share calendars, share contacts, and more. Team Folders are essentially Web pages you can view in Outlook that allow you to share Outlook objects and Office documents.
The easiest way to work with Team Folders is to use the Team Folders Kit. The kit includes the Team Folders Wizard -- used to create Team Folder applications. Team Folders did not ship as part of Microsoft Outlook 2000 and is available only via download from the Microsoft Web site at http://www.microsoft.com/exchange/collaboration/TFWizard.htm. To use Team Folders, all team members must have both Microsoft Outlook 2000 and Microsoft Exchange Server installed.
The Outlook 2000 Team Folder Wizard offers six templates that are easy to set up and administer. The templates include:
The Outlook 2000 Team Folder Wizard allows you to create a collaborative workgroup environment: build a document-sharing tool; set up meetings with the calendaring feature; post project-related task lists; benefit from real-time online discussions; and access all project-related information in one location.
That gets me to the bottom of the mailbag, at least for items concerning Microsoft Outlook. Check out the following links for more information.
David Shank is a Programmer/Writer on the Office team specializing in developer documentation. Rumor has it he lives high in the mountains to the east of Redmond and is one of the few native Northwesterners still living in the Northwest.