• United States

Making Outlook work for us, Part II

Apr 19, 20044 mins
Enterprise ApplicationsMessaging Apps

Last week at the start of our quest to make Microsoft Outlook do what we want – that is, launch an application when an appointment or task item reminder occurs – we first had to stop Outlook from having a cow every time we started it with macros (aka scripts) installed. Thus we went down the labyrinthine path to create self-signed certificates that let Outlook turn a blind eye to our code.

It appears that some of you have benefited from our expiation of this particular bit of Microsoft arcana. Reader Bruce Whitlock wrote: “The column on Outlook was timely, encompassing and, most important to me, accurate.” We aim to please.

This week we’ll show you how to launch an application from an Outlook reminder.

First, in the Outlook menu go to Tools | Macro | Visual Basic Editor, or simply press Alt + F11 and you will find yourself in the VBA Editor. In the left pane you will see a hierarchy starting with Project1 (VbaProject.OTM), under which you will see (when you expand the branches) Microsoft Office Outlook Objects and under that ThisOutlookSession. The right pane now will list the various subroutines and functions you have defined by loading macros and extensions under Outlook. Put the following code in that pane:

Private Sub Application_Reminder(ByVal Item As Object)

If (TypeOf Item Is AppointmentItem) And _

(Item.Categories = “AppRun”) Then _

Call RunApp(Item)

End Sub

Public Function RunApp(ByVal Item As AppointmentItem)

Dim WSHShell

Item.ReminderSet = False

Item.Close (False) ‘close reminder popup

Set WSHShell = CreateObject(“wscript.Shell”)

WSHShell.Run Trim(Item.Body), 1, False

Set WSHShell = Nothing

End Function

The first line sets up an event handler for Outlook reminders. When a task or an appointment triggers a reminder, the handler subroutine named Application_Reminder will be called.

The calling routine – Outlook itself – will pass the handler an object so we first must test the object to see if it is an AppointmentItem. The alternatives are MailItem, MeetingItem or TaskItem, and we could choose to launch applications from any of these. TaskItems would be a sensible alternative as well as or instead of AppointmentItems.

Once we know the object is an AppointmentItem we can test its Categories attribute value to see if that equals AppRun (you could look for any category or categories you like – nothing restricts you to just one). If the value is what we’re looking for, we now call the function RunApp.

RunApp first clears the ReminderSet property of the item and then executes the close method, which updates the object’s properties. This should suppress the reminder alert dialog if you have enabled it, but the dialog seems to get called anyway (although the reminder we just cancelled does not appear). This is very annoying. If you know how to prevent this, please let us know.

Next we call the Windows Script Host to access a native Windows shell. This shell lets us run a program locally, manipulate the contents of the registry, create a shortcut or access a system folder. We are going to run a program.

The trim function strips leading and trailing spaces from the string that we extract from the object’s “body” – that’s the optional descriptive text, which is another property of the object. We then pass this string to the shell instructing the shell to execute it. The next argument, “1,” specifies that the window should be activated and displayed (if the window is minimized or maximized, the system restores it to its original size and position). The final argument, “False,” causes control to immediately return to our script ignoring any error code from the shell (in other words, if the program doesn’t exist or something else goes wrong our script doesn’t care).

When the reminder actually occurs will depend on how far in advance of the event we set it. But don’t assume that the application will be launched exactly on the minute that you specify – on our test system the reminder usually triggered about 40 seconds after the target time was reached – an odd behavior that is because of the internal architecture of Outlook.

If you need accurate launching of an application you might want to ensure that the reminder occurs a few minutes before the desired start time and hand the details of the program to be executed to an external application along with the start date and time (which would be referenced in our example as Item.Start).

Is that it? Nope. There’s more next week. Remind us at


Mark Gibbs is an author, journalist, and man of mystery. His writing for Network World is widely considered to be vastly underpaid. For more than 30 years, Gibbs has consulted, lectured, and authored numerous articles and books about networking, information technology, and the social and political issues surrounding them. His complete bio can be found at

More from this author