Outlook Automation – Showing the Outlook Main Window

by Philipp Stiefel, originally published 2023-06-01

last revision on 2023-05-25

Photo by Simon Hrozian on Unsplash

Often, we employ Outlook Automation to quickly send an email. In this case there is no need to display the Outlook main window. If we want to display the email we just created instead of sending it right away, we simply use TheMailItem.Display instead of .Send to show the created email message.

Now, what if we actually want to show the Outlook main window to the user? – Unfortunately, it is not as simple as setting Visible=True.

Displaying the an Outlook Main Window

The first important thing to understand is that there is not the universal Outlook main window. For some time now, a single Outlook instance is capable of displaying multiple independent windows. Which Outlook folder such a “main window" displays, either depends on user interaction in the UI, or on startup on the current user’s settings (“Options” - “Advanced” – “Start Outlook in this folder”).

If we start Outlook by COM automation, e.g., with CreateObject("Outlook.Application"), a new Outlook instance is created. This instance is hidden, and it does not create any main window at all; probably because loading the data to show a main window takes some time and is not required in many cases.

So, if we want to display an Outlook main window from an instance created by automation, we first must tell Outlook what this window should show, i.e., which folder to display.

The following code sample creates a new Outlook instance and displays the Inbox folder of the primary email account.

In the Outlook object model a main window is an object of type Explorer. When we just call the .Display method of an Outlook folder, an Explorer window with default settings is created to display the content of the folder. In theory, we could control the layout of the explorer created either by using the GetExplorer method of the Outlook folder, or by using the .Add method of the Application.Explorers collection and supplying an value for the DisplayMode argument of either of these methods. In practice, however, there is little to gain from this because it appears that the Outlook Team broke some of this functionality when they recently redesigned the Outlook UI. Currently OlFolderDisplayMode.olFolderDisplayFolderOnly appears to have no effect and olFolderDisplayNoNavigation hides the navigation elements as intended, but still leaves the screen area where the navigation elements would have been, as dead unusable space.

Even though it has little practical value in this context, here is an example showing the above discussed methods of explicitly creating the Explorer window and displaying it.

If we want to control the window state (normal, minimized, maximized) of the Outlook Explorer window we created, we set the WindowState property of the object.

Displaying the User’s Startup Folder

Starting Outlook as an automation server usually involves a specific task you want to accomplish by automation. So, if you want to display an Outlook window, it is most the task at hand will decide over the most sensible folder to display.

However, if there is no task-centric folder you want to display but you want to show the user configured default startup folder instead, there’s a bit of work to do. Unfortunately, there is no simple GetOption method like in Access to read the user’s configured preferences for Outlook. Instead, you need to retrieve those values from the Windows Registry.

Uncharted Territory Warning

The main problem with retrieving these settings from the Registry is that they are not officially documented. There are some “magic values” involved and I hard to research whether these are hardcoded values valid with every Outlook installation, or whether they need to be retrieved from somewhere on individually on each computer.

Registry Structure

On my computer the startup folder EntryId is stored in the value “001e0336” in the Registry key “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\Profiles\Outlook\0a0d020000000000c000000000000046”.

I believe the value name “001e0336” is a hardcoded identifier for the “Start Outlook in this folder” option of Outlook, as all values in the parent key are strings of hexadecimal numbers and they appear to be the same on every computer.

The value “0a0d020000000000c000000000000046” seems to be an identifier for the sub section of the Outlook profile in the Registry storing a part of the preferences from the Outlook options, including the “Start Outlook in this folder” option. I found this GUID in a German Microsoft Exchange FAQ text. So, it is also a hardcoded value, which should work with every Outlook installation.

The second occurrences of ”Outlook” in the registry key path “…Outlook\Profiles\Outlook\...” is the mail profile I use, which happens to be named “Outlook”. You can retrieve the name of the current profile by using the Namespace.CurrentProfileName property.

Sample Code

So, taking all the above findings into account, I wrote the following sample code to run Outlook and display the user configured startup view.

If there is no EntryId of a startup folder stored in the Registry, the code will display the Inbox of the primary mail account, as Outlook would do when started normally.

In the GetUserStartupFolderEntryIdFromRegistry function I used my own Registry class module, but you can use any other suitable means to read the EntryId of the startup folder from the Windows Registry.

Wrap Up

With the above code and explanations, you should now be able to display an Outlook main window showing either the folder you selected or alternatively the user configured startup folder.

I hope you learned something new and that the information in this text helps you with some of your Outlook programming tasks.

Share this article: