Office Space: Tips and Tricks for Scripting Microsoft Office Applications

Welcome to Office Space, the column that offers tips and tricks for scripting Microsoft® Office applications. We’ll post new tips every Tuesday and Thursday; to see an archive of previous tips, visit the Office Space Archive. And if you have particular questions about Microsoft Office scripting, feel free to send them to scripter@microsoft.com (in English, if possible). We can’t promise to answer all the questions we receive, but we’ll do our best.

Starting a Script Regardless of Whether or Not Microsoft Outlook is Already Running

Suppose you bought a DVD drive from a computer store and the installation instructions consisted entirely of the following:

“After installing the drive replace the cover on the computer.”

Very helpful advice, provided you’ve already installed the DVD drive. But what if you haven’t installed the DVD drive? In that case, what good are these instructions? You wouldn’t be too happy with the DVD manufacturer and we don’t blame you. Documentation isn’t of much use when it assumes you’ve already performed certain steps, especially when it’s almost certain that you haven’t performed some of those steps.

So do the Scripting Guys ever operate under such unrealistic assumptions? Of course we don’t…well, most of the time. As much as it pains us to admit it, however, we sometimes make unwarranted assumptions when it comes to scripting. Case in point: any time we write about Microsoft Outlook we always include this blithe note:

“For this script we’ll assume that Microsoft Outlook is already running.”

Very helpful advice, provided that Microsoft Outlook is already running. But what if it isn’t? In that case, what good does the script do you? Are the Microsoft Scripting Guys just as irresponsible as our hypothetical DVD manufacturer?

That’s a tough question (although we do know how our managers would answer it). But at least the Scripting Guys recognize the fact that we’re sometimes a bit remiss in our duties. Today we’ll show you some code that checks to see whether or not Outlook is running. If it is, then the script binds to the existing instance of Outlook and reports back the number of items in the Inbox. (A somewhat meaningless task, but we had to have it do something just so you’d know that the script was working.) If Outlook isn’t running the script starts the application and then reports back the number of items in the Inbox. After today you’ll never have to worry about whether or not Outlook is running before you execute a script. Promise.

Here’s our script, with an explanation to follow:

Const olFolderInbox = 6

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery _
    ("Select * From Win32_Process Where Name = 'outlook.exe'")

If colItems.Count = 0 Then
    Set objOutlook = CreateObject("Outlook.Application")
    Set objNamespace = objOutlook.GetNamespace("MAPI")
    objNamespace.Logon "Default Outlook Profile",, False, True    
    Set objFolder = objNamespace.GetDefaultFolder(olFolderInbox)
    objFolder.Display
    Set colItems = objFolder.Items
    Wscript.Echo colItems.Count
Else
    Set objOutlook = CreateObject("Outlook.Application")
    Set objNamespace = objOutlook.GetNamespace("MAPI")
    Set objFolder = objNamespace.GetDefaultFolder(olFolderInbox)
    Set colItems = objFolder.Items
    Wscript.Echo colItems.Count
End If

The script starts out by defining a constant named olFolderInbox and setting the value to 6; we’ll use this later on to tell the script to connect to and then display the Inbox. We then use some good old-fashioned WMI code to return a collection of all the processes currently running on the local computer, or at least all the processes with the executable file name outlook.exe. That’s how we know whether or not Outlook is running: if we find a process named outlook.exe, we assume Microsoft Outlook is running. If we don’t find such a process, then we assume that Outlook is not running.

So how do we know whether or not any processes named outlook.exe were found? That’s easy. All WMI collections contain a property named Count; as the name implies, Count tells us the number of items in the collection. If the Count is equal to 0 that means no process named outlook.exe is running; if the count is not equal to 0 then a process named outlook.exe is running.

So what happens if the Count is 0, meaning that Outlook isn’t running? In that case we run this block of code:

Set objOutlook = CreateObject("Outlook.Application")
Set objNamespace = objOutlook.GetNamespace("MAPI")
objNamespace.Logon "Default Outlook Profile",, False, True    
Set objFolder = objNamespace.GetDefaultFolder(olFolderInbox)
objFolder.Display
Set colItems = objFolder.Items
Wscript.Echo colItems.Count

This section of the script begins by creating an instance of the Otloook.Application object, then using the GetNamespace method to connect to the MAPI namespace (which, interestingly enough, is the only namespace we can connect to). We then call the Logon method to ensure that we connect to the proper Outlook profile. The Logon method requires four parameters:

After connecting to the correct profile we use the GetDefaultFolder method to bind to the Inbox and then call the Display method to show the application on screen. Note that this is different from other Office programs; in Word or Excel, for example, you create an instance of the Application object and then set the Visible property to True. That’s not how things are done in Outlook. Here we bind to a namespace and a folder, then call the Display method to make our folder – and the rest of Outlook – visible.

Next we use these two lines of code to return a collection of all the items in the Inbox and then echo the value of the Count property; this tells us how many items are in that collection:

Set colItems = objFolder.Items
Wscript.Echo colItems.Count

That’s all we have to do. As you can see, it’s actually pretty easy to determine that Outlook isn’t running and then startup and log on to the application.

But what if Outlook is running? No problem; in that case we just run this block of code instead:

Set objOutlook = CreateObject("Outlook.Application")
Set objNamespace = objOutlook.GetNamespace("MAPI")
Set objFolder = objNamespace.GetDefaultFolder(olFolderInbox)
Set colItems = objFolder.Items
Wscript.Echo colItems.Count

There are only two differences here. First, we don’t need to use the Logon method to log on to Outlook; after all, we’ve already logged on. Likewise we don’t need to use the Display method to make Outlook visible; most likely Outlook already is visible. And that’s it; the rest of the code is exactly the same.

So there you have it, a script that will work regardless of whether or not Outlook is already running. And, no, it doesn’t really help you install that DVD drive. But look on the bright side: at least now you can connect to Outlook and send an angry letter to the manufacturer.