Like many of you, I'm highly dependent on e-mail. It's difficult to imagine trying to get by without using e-mail to communicate quickly and easily with clients, editors, friends, and colleagues. Yet e-mail has its downside too. This is most evident when I log on to find dozens, if not hundreds, of messages waiting for me. Of course, I can't ignore them. There are certainly some important missives that I need to respond to immediately, if not sooner. But these vital messages are hidden, like wheat among the chaff, amidst everything from pure spam to a note from my mother. How can I deal with this mass of messages in an efficient manner?

One possibility for managing e-mails is to use Outlook's Rules Wizard. This tool permits you to define rules, or actions, that are applied to messages as they arrive. You could, for example, specify that any message with the words "WIN FREE MONEY" in the subject line should be deleted immediately. FIGURE 1 shows the Rules Wizard dialog box, with a list of defined rules at the top and the content of the selected rule at the bottom. While the Rules Wizard is reasonably flexible, it does have some limitations and can be rather cumbersome to use. Is there a better way?

FIGURE 1: Outlook's Rules Wizard dialog box.

Yes! And as you've probably guessed, it involves writing a macro with Visual Basic for Applications (VBA). With the power of a full-fledged programming language at your disposal, there are essentially no limitations as to how you can manage e-mail messages. You can implement whatever management scheme is dictated by your needs, or the needs of your client.

Another advantage is that VBA projects provide some security options that aren't available with the Rules Wizard. This doesn't mean that the Rules Wizard is useless and should be abandoned altogether, but if you know how to filter and handle your incoming e-mail with VBA, then you can choose the approach that best fits your circumstances.

The Outlook Object Model

To work with mail messages, you need to understand Outlook's object model. Actually, you only need to understand part of it. Remember, Outlook does many things besides e-mail; it has the Calendar, Journal, Contacts, Notes, and Tasks. However, these parts of Outlook aren't relevant to the present discussion.

Like all other Office applications, the Outlook object model has the Application object at the top of the object hierarchy. To do anything programmatically with Outlook, you must have a reference to this object. If you are creating e-mail management code inside Outlook, the Application object is always available as an implicit reference. You don't need to create a reference to this object or refer to it in your code. If you're creating code outside Outlook - in Word, for example - you'll have to explicitly create a reference to the Outlook Application object, as shown here:

SAMPLE ONE:(below)

You'll also need to explicitly include this reference in your code. For this article, however, I'll assume your code is being written within Outlook, so these steps won't be necessary.

FIGURE 2 diagrams the parts of Outlook's object model that you need for the current task. You can see the Application object at the top, with other objects and collections below it. These other objects will be explained in due course, but first I'll address the details of writing VBA code in Outlook.

FIGURE 2: The parts of the Outlook object model used in this article.

If you have no experience writing VBA code in Outlook, you may be wondering where exactly this code should be placed. Press [Alt][F11] to open Outlook's VB Editor (VBE), which is shown in FIGURE 3. In the upper left pane, open the project by clicking the adjacent + sign, and then open Microsoft Outlook Objects. Finally, click on ThisOutlookSession to display its code in the pane on the right. Your project may be empty, or it may already contain code. Finally, click on the right pane to make it active; this is where you'll enter and edit your code.

FIGURE 3: The Outlook VB Editor.

Outlook handles VBA projects differently from other Office applications. Word, Excel, and PowerPoint associate a VBA project with a specific document or template. Outlook doesn't have documents, so projects are associated with the Outlook application itself. There can be only one Outlook VBA project per user, and it's stored in the file, VbaProject.OTM. When only a single user is set up with Windows 95/98/00/ME, this file is kept in c:\Windows\Application Data\Microsoft\Outlook. When multiple users are set up, the file for each user, username, is kept in c:\Windows\Profiles\username\Application Data\Microsoft\Outlook. Windows NT keeps the file in c:\Winnt\Profiles\username\Application Data\Microsoft\Outlook.

The next step is to create a procedure to contain your code. Decide on a name for the procedure; a name that describes what the procedure does, such as "ProcessEmail." Then follow these steps:

1) Select Procedure from the Insert menu. The Add Procedure dialog box will be displayed.

2) Enter the procedure name in the Name textbox.

3) Make sure that the Sub and Public options are both selected, and that the All Local variables as Statics option is not selected.

4) Click OK.

The editor will insert the first and last lines of the procedure into the editing window, as shown in FIGURE 3. You'll place your code between these two lines.

Now that you understand the mechanics of creating a VBA procedure in Outlook, let's look at the object model in more detail. First, however, read over the following outline of the specific tasks that this procedure will perform:

1) Obtain a reference to the Inbox folder, where Outlook places newly arrived messages.

2) Examine each message in the Inbox and compare its subject and sender to certain criteria.

3) If a message meets certain criteria, delete it.

4) If a message meets certain other criteria, move it to the folder named "Immediate Attention."

5) Otherwise, do nothing with the message (leave it in the Inbox).

This list constitutes a fairly simple approach to e-mail processing, but it will serve to demonstrate the programming techniques we're interested in. Once you understand the fundamental techniques, you can expand your processing criteria to include the message importance, its text, its send date, its recipients, and so on.

Obtaining Folder References

To read a message or to move a message to another folder, you need to obtain a reference to the folder that the message is in, or the folder where it will be moved. Almost anything you do programmatically in Outlook, including obtaining folder references, involves the Namespace object. Outlook is designed to handle more than one namespace, with each namespace representing a different source of data. At present, however, only a single data source, named MAPI, is supported. To work with the MAPI namespace, you obtain a reference to the MAPI Namespace object, as follows:

SAMPLE TWO: (below)

Once you have a reference to the Namespace object, you're ready to obtain your folder references. For the Inbox folder, this is a simple process; because the Inbox is one of Outlook's default folders, you can use the GetDefaultFolder function. Its syntax is:

Once you have a reference to the Namespace object, you're ready to obtain your folder references. For the Inbox folder, this is a simple process; because the Inbox is one of Outlook's default folders, you can use the GetDefaultFolder function. Its syntax is:


where folder is a constant identifying a specific default folder. The constants for the e-mail-related default folders are as follows (with the constant's current value in parentheses):

-olFolderDeletedItems (3)
-olFolderDrafts (16)
-olFolderInbox (6)
-olFolderOutbox (4)
-olFolderSentMail (5)

The following code, for example, obtains a reference to the Inbox folder:

For non-default folders - ones you've created in Outlook - the process isn't so simple. You must look through the existing folders until you find one with the desired name. This is done using Outlook's Folders collections. Here's how things are organized:

The Namespace object has a Folders collection that contains all of the namespace's top-level folders. Each folder is represented by a MAPIFolder object. Typically, there's only one top-level folder in Outlook, named Personal Folders.

Each top-level folder has its own Folders collection, which contains one MAPIFolder object for each subfolder. Typically, the Personal Folders folder contains the Inbox folder, the Deleted Items folder, the Sent Items folder, as well as any custom folders you've created. Each subfolder has its own Folders collection, containing subfolders. There's no limit on the number of levels of nesting of subfolders. If a folder doesn't contain any subfolders, its Folders collection will be empty.

To locate and obtain a reference to a non-default folder, you need to look through the Namespace object's Folders collection, and then through the Folders collection of each of those folders until all levels of subfolders have been examined. For each folder, look at the MAPIFolder.Name property to determine the folder name. I don't have the space in this article to explain the details of using collections, but the following code shows how it's done (you can refer to the VBA online help for more information on collections):

SAMPLE FOUR: (below)

This code looks through all the first-level subfolders (that is, those folders at the same level as the Inbox) for a folder named "Immediate Attention." If the folder is found, the variable FoundFolder is set to refer to it. Otherwise, this variable will hold the special value Nothing. The code assumes that myNS is a reference to the MAPI Namespace object.

Once you have a reference to a non-default folder, you can access the messages it contains. More important to the current task, you can also move messages to the folder. You'll see how this is done soon.


Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.