Objective Exposure

The process of automation allows you to script your way through Office applications—even Outlook. Here’s how.

• By Chris Brooke
• April 01, 2001

Back in November, I asked you to send me your suggestions for where you would like me to take this column. What areas of scripting do you want to learn? To encourage the shy, I offered incentives in the form of a prize if I used your suggestion. Over the next several months, I’ll be covering some of these suggested topics in detail. Because you know how I love to keep you in suspense, I’m not going to tell you the names of the winners until we cover their suggested topics.

And The Winner Is...
The first winning suggestion was submitted by Don Baker, an MCSE from Internosis.com. Don wins a copy of Scripting Windows 2000 by Jeffrey Honeyman (Osborne/McGraw-Hill). Actually, Don had several ideas. I may ultimately get to them all because I really liked them (don’t worry—he can only win one prize), but I’ll start with his first request: Outlook automation!

You’ve Been Exposed
If you’ve ever used any of the Microsoft Office suite of programs, you know about Object Linking and Embedding (OLE), which allows you to place an Excel spreadsheet into a Word document or put an AVI file in your PowerPoint presentation. Well, OLE is simply part of COM (Microsoft’s Component Object Model), and COM is exposed to the Windows Script Host. Therefore, as long as the application has an exposed object model (and virtually all Microsoft apps do), you can access it from your scripts to create and edit its documents or files. In other words — you can access an application as you would a component. The process is called automation, and it’s really cool!

Model Behavior
To find out what you can actually do with the application from within our scripts, we need to take a look at its object model. For components, the object model is represented in the DLL or OCX (remember all those times I used X-Ray to look at components?). In an application, the object model is usually expressed in a type library file (.tlb or .olb). You can look at these files using X-Ray in the same way you look at DLLs. In fact, if you recall, the Active Directory object model I referred to so often over the last few months was in the form of a .tlb file.

Figure 1 shows the Outlook object model viewed with X-Ray. The file — MSOUTL9.OLB — is located (along with all the other Microsoft Office object models) in your Office directory. Assuming you installed Office with the default settings, this will be C:\Program Files\Microsoft Office\Office. Next time you have some spare time (not now, of course—I need your full attention), search your entire hard drive for files with .OLB and .TLB extensions. You may be surprised to discover how many applications allow automation.

Figure 1. The Outlook Object Model shows which interfaces are exposed for automation.

Although X-Ray shows all of the exposed interfaces, I find that the Visual Basic Object Browser is easier to look at. For one thing, it’s sizeable. You can also load multiple libraries and switch between them. That right there is worth the price of admission! Figure 2 shows the same Outlook object model viewed in the VB Object Browser. See what I mean?

Figure 2. The Visual Studio Object Browser allows viewing of multiple types of libraries.

The Deep End of the Pool
As you browse the object model of Outlook, you may become a bit overwhelmed. There are tons of exposed properties, methods, constants and more. Don’t try to understand it all just yet. Many of these properties and methods you may never have to use. I’ll start with something simple: Starting Outlook and sending an e-mail message.

' SendEmailMessage.vbs
Option Explicit
Dim objOutlook, clsMessage, clsRecipient

' Open Outlook Session
Set objOutlook=CreateObject("Outlook.Application")
Set clsMessage=objOutlook.CreateItem(0) ' Value of ' 0=MailItem

With clsMessage
Set clsRecipient=clsMessage.Recipients.Add(
"Chris Brooke")
clsRecipient.Type=1 ' Value of 1="To"

clsMessage.Subject=”The Server Just Went Down!!!”
clsMessage.Body="The Server went down at "
& Time & "on "& Date
clsMessage.Importance=2 ' Value of 2=Important

clsRecipient.Resolve
If Not clsRecipient.Resolve Then
clsMessage.Display
End If
clsMessage.Send
End With

Set clsMessage=Nothing
Set objOutlook=Nothing
WScript.Quit

Let’s review what’s been done. In line 5, I create the automation object and start Outlook. I tell the Outlook object to create a new object, specifically a new message, by executing the “CreateItem(5)” method. The object model contains a list of constants that tells you what number corresponds to what item. More constants are also used in lines 8 and 11 for placing the recipient on the “To” line and specifying that the message is high priority. I then set the properties of the message, including the subject line and the message body. Now I’m ready to send. First, I must resolve the name in the Outlook address book. Line 11 tells the script to display the message on the screen if the recipient name can’t be resolved. I can also add alternate recipients at this point and try again. Once I’ve resolved the name, I send the message.

Additional Information For more information about Outlook Automation go to http://search.support.microsoft.com/kb. Choose Outlook from the pull down menu; click "search by specific article ID number;" and read articles Q201096, Q208527, Q146636 and Q271225.

Let’s Get WITH It
You’ve probably noticed that I’ve included a VBScript command I haven’t yet covered: the WITH statement. This will really save on typing when dealing with objects, classes or user-defined types. Simply tell VBScript that you’re going to be working “WITH” a particular object, and every time you precede a property or method with a dot (“.”), VBScript uses the object specified in the WITH statement. END WITH puts things back to normal.

Next month, I’ll look at other ways to use automation with Outlook (and perhaps Word) to accomplish some other tedious administrative tasks.