I got some great questions recently about macros and Protected View in Word 2010, and thought I'd write something up to help anyone else who's looking at this issue - enjoy!

Word 2010 includes enhancements to security, one of which is the inclusion of a Protected View used when opening files from untrusted sources (e.g. email attachments). The inclusion of Protected View can require changes to the way that solutions interact with Word documents, as some object model methods/properties are disabled while in Protected View.

What is Protected View?

This introductory post on the Office 2010 Engineering blog provides an excellent description of Protected View.

In short, Protected View provides a safe read-only view of all untrusted Office documents which allows you to view the document content without the need to worry about documents from malicious sources causing damage to your computer.

It looks like Word because it is Word; it's just a version of Word that has been carefully restricted to prevent malicious content from accessing any other part of your computer. With Protected View, you can view files without worrying about their source.

Protected View and Macros

Part of the restricted environment provided by Protected View limits the access that documents in this view have to Word's object model – the following sections describe how macro behaviors change when documents are opened in Protected View, and how you can write code that's compatible with Protected View windows.

Document Events in Protected View

When a document is opened in Protected View, document events are limited as follows:

• Any macros in the document itself are not triggered.
• The Open event on the Document object is not triggered.
• The DocumentOpen event on the Application object is not triggered.
• The ProtectedViewWindowOpen event on the Application object is triggered.

As well, an AutoOpen macro stored in any global document template will be executed.

If the user chooses to enable editing of the document (leaving Protected View), all appropriate events will be triggered at that time, and any associated code will be executed.

The Protected View Events section below describes all of the events which can be captured for Protected View windows.

Detecting Protected View

If macro code (for example, an AutoOpen macro) is run in a context in which in which the document is in Protected View, either of the following mechanisms can be used to detect this condition:

• The ActiveProtectedViewWindow property on the Application object will not be null (or Nothing)
• The Count property of the Documents collection will be non-zero, but the ActiveDocument property of the Application object will return an error

The following sample macro shows a dialog box only if the document is in Protected View:

Sub Test()
    If Not Application.ActiveProtectedViewWindow Is Nothing Then
        MsgBox "In Protected View"
    End If
End Sub

Getting the Active Document/Window in Protected View

Without access to the ActiveDocument property of the Application object, the following methods must be used to get the current document and window objects:

• To retrieve the current window, access the ActiveProtectedViewWindow property on the Application object
• To retrieve the current document, access the Document property on the ActiveProtectedViewWindow object.

The following sample macro shows the file's location in a dialog box only if the document is in Protected View:

Sub Test()
    If Not Application.ActiveProtectedViewWindow Is Nothing Then
        MsgBox Application.ActiveProtectedViewWindow.Document.FullName
    End If
End Sub

Protected View Events

Architecturally, as described in the blog post referenced above, the protection in Protected View is accomplished by splitting the Word window into two processes: a host process that owns the top level application frame window, which includes the window caption, the ribbon, the trust bar, status bar, etc. and a client process that loads and displays the document content. Accordingly, the object model allows macros to access an Application object corresponding to the trusted host process, and an Application object corresponding to the untrusted client process.

While a document is in Protected View, Word provides a specific set of application-level events that allow for control of the Protected View window via those two Application objects:

Standard Window Events

For each of the Application object's window-level events available while not in Protected View, an analogous event is available in Protected View as well:

The following events are triggered from either Application object with the corresponding event handlers:

• The ProtectedViewWindowActivate event, which is triggered under the same conditions as the WindowActivate event
• The ProtectedViewWindowDeactivate event, which is triggered under the same conditions as the WindowDeactivate event
• The ProtectedViewWindowSize event, which is triggered under the same conditions as the WindowSize event

The following events are only triggered from the Application object for the client process (the object returned from the Application property of the Document property of a ProtectedViewWindow object):

• The WindowBeforeDoubleClick event
• The WindowBeforeRightClick event
• The WindowSelectionChange event

The following sample code shows how a solution can capture the WindowSelectionChange event via the Application object for the Protected View window, by first using the ProtectedViewWindowOpen event to get the Application object:

Dim WithEvents oApp as Application
Dim WithEvents oAppProtView As Application

Sub AutoOpen()
    Set oApp = Application
End Sub

Private Sub oApp_ProtectedViewWindowOpen(ByVal Window As ProtectedViewWindow)
    Set oAppProtView = Window.Document.Application
End Sub

Private Sub oAppProtVew_WindowSelectionChange(ByVal Sel As Selection)
    'code to handle event would go here
End Sub

Protected View-specific Window Events

Along with the events triggered while not in Protected View, three additional events are available for solutions that interact with Protected View windows:

• The ProtectedViewWindowOpen event is triggered when a new Protected View window is opened (i.e. a document is opened into Protected View)
• The ProtectedViewWindowBeforeEdit event is triggered when a user takes an action to edit a document that was opened in a Protected View window (e.g. when the user clicks Enable Editing on the business bar that appears in the Protected View window)
  • This event accepts a Cancel parameter that can be used to cancel the edit action
• The ProtectedViewWindowBeforeClose event is triggered when a user takes an action to close a Protected View window (e.g. when a user closes a window from the close button in the top-right corner)
  • This event accepts a Cancel parameter that can be used to cancel the close action (unless the close action occurs as part of a transition to editing the document)

The following sample code illustrates how an add-in might capture the events available in Protected View to perform logic before a file in Protected View is edited:

Dim WithEvents oApp as Application

Sub AutoOpen()
    Set oApp = Application
End Sub

Private Sub oApp_ProtectedViewWindowBeforeEdit(ByVal Window As ProtectedViewWindow, Cancel As Boolean)
    'code to run before the file can be edited goes here
End Sub

Conclusion

Although Protected View requires some modifications to existing solutions, solutions can easily detect when a window is in Protected View and:

1. Do nothing (i.e. notice that the window is in Protected View and exit), as events will be triggered as usual if/when the user attempts to edit the document
2. Use the additional objects/events available in this view to interact with the document as needed

- Tristan