Understanding the Difference between Custom Task Panes and Action Panes
To the user, custom task panes and action panes have an identical appearance. Custom task panes and action panes consist of some screen real-estate that co-exists with the open document or spreadsheet within the Office client. This real-estate can be docked to the right, bottom, left, or right of the document or spreadsheet. It can also be a floating window.
This blog is inactive.
New blog: EricWhite.com/blog
Blog TOCThis post is one in a series on Microsoft Office 2010 application development. These posts will be published in the future as part of an MSDN article. As usual, after the MSDN article is published, I’ll place pointers in the blog posts to the article on MSDN.
- Office/SharePoint Building Blocks and Developer Stories
- Overview of Office 2010 Application Development
- Office Application Scenarios
- Understanding the Three Approaches to Office Development using VSTO
- What is the Difference between ‘Word Automation’ and ‘Word Automation Services’?
- Understanding the Architecture of Office 2010 Managed Add-Ins and Customizations
- Understanding the Difference between Custom Task Panes and Action Panes
- Microsoft Word 2010 Developer Building Blocks
- Comparing Excel Automation to Excel Services
The following screen clipping shows a custom task pane for an application-level add-in.
The following shows an action pane associated with a spreadsheet.
As you can see, custom task panes and action panes look very similar. There is one key difference. Custom task panes are associated with an application-level add-in in Excel, InfoPath, Outlook, PowerPoint, and Word. Action panes are associated with a document-level customization in Word and Excel only. With an application-level add-in, if the custom task pane is visible, it is visible regardless of which document or spreadsheet is the active one. With a document-level customization, the action pane is visible only if the customized document or spreadsheet is active.
Note that it is more common to build application-level add-ins and to use custom task panes. If you are building a document-level add-in, make sure that your scenario requires the additional complexity of attaching a code-signed assembly to documents and/or spreadsheets.
A note on nomenclature: As delivered, the Office client applications make use of task panes for a variety of purposes. The styles window (which you have probably used frequently) is a task pane. Most often, you see the styles task pane as a floating window, however, you are free to dock it to one side of the application. When you create a task pane for a managed add-in, it is a custom task pane.
There are a few final points to make about the difference between application-level add-ins and document-level add-ins.
With application-level add-ins, it is significantly easier to operate on all open documents or workbooks if you need to. Document-level add-ins, in contrast, are designed to work with one specific document. If you need to process or programmatically examine any or all open documents or spreadsheets, you should use an application-level add-in.
The root object when working with application-level add-ins is an Application object. In the case of Word, it is an object that implements the Microsoft.Office.Interop.Word.Application interface. For Excel, it is Microsoft.Office.Interop.Excel.Application.
The root object when working with document-level customizations is a document or spreadsheet. For Word, the root object implements the Microsoft.Office.Interop.Word.Document interface. For Excel, it is Microsoft.Office.Interop.Excel.Workbook.