Do you know about the new Outlook add-in that automates highlighting of your search string in an email message? The Visual How To, Automating Search Highlighting in Outlook 2010, provides a real add-in that you can build in Visual Studio and run with Outlook 2010, and that improves your experience searching for email content. Read on to also learn about doing programmatic searches and customizing the ribbon in Outlook!
Improving Search Experience
In Outlook, you can use Instant Search to search for items in a folder that contain a string of your choice. For example, you can search for “office”. Instant Search returns items that contain “office” in the subject or body, in the Outlook explorer. However, when you open a returned item in an inspector, the search string is not highlighted in the email body, as shown in the following screen shot.
You will have to click Find in the Editing group of the Message tab, enter the search string again, and then click Find Next in order to see the occurrences within that email. These extra steps can be tedious if you are looking through multiple returned results to compare their content in inspectors.
This add-in allows you to use just a single click to open a returned result, and all occurrences in the email body would be automatically highlighted in the mail inspector. See the following screen shot.
The next screen shot shows the custom interface to use this custom search, and the regular user interface of Instant Search provided by Outlook.
The custom search interface contains a text box, a search icon, and an Open Message with Highlights button.
The text box plays a similar role as the Instant Search text box, and is there just to provide the search string entered by the user to the add-in.
The following is the typical user search scenario:
1. Enter a search string in the text box adjacent to Search for.
2. Click Enter or the search icon to initiate the Instant Search.
3. From the list of search results returned by Instant Search, single-click a result item.
4. Click the Open Message with Highlights button.
5. The add-in opens the item in an inspector with all occurrences of the search string in the item’s body highlighted.
Aside from improving the search experience with automatic highlighting, this add-in shows 2 ways of performing programmatic search in Outlook:
· Using Explorer.Search to perform Instant Search on items in a folder
· Using the Microsoft Word object model to search in a mail or meeting item in an inspector. That is, use the Inspector.WordEditor property to obtain the Word Document object, then get the Range object that represents the entire email body, and use the Find object to search and highlight occurrences of the original search string.
Note: In Outlook, because a mail folder can contain mail items as well as other item types such as meeting item responses, before opening a search result item in an inspector, the add-in first has to identify the type of the selected item, and then uses the appropriate inspector to open the item. For example, the add-in uses MailItem.Display if the item is a mail item, and MeetingItem.Display if the item is a meeting item.
There are other ways to perform searches in Outlook, see Enumerating, Searching, and Filtering Items in a Folder for details.
This add-in also provides a useful example of how to customize the ribbon to meet its specific needs:
· In order to search only mail folders, this add-in adds a custom tab to the ribbon on the mail explorer, but not to the ribbon for the other explorers such as the contacts explorer. To do that, in the ribbon XML, only specify idMso as TabMail, as shown below:
<ribbon>
<tabs>
<tab idMso="TabMail">
<group id="CustomSearch" label="Custom Search">
· When you initiate Instant Search and when Instant Search returns, Outlook defaults to the Search Tools contextual tab in the explorer. In this scenario, after returning from Instant Search, the user should return to the Custom Search tab in order to use the custom button to open the message with highlighting. To achieve that, after returning from Explorer.Search, do the following:
ribbonUI.ActivateTabMso("TabMail")
· If the user switches to a different folder to do a new search, the add-in should clear the search text box to prepare for a new search. The add-in listens to the Explorer.FolderSwitch event and calls the IRibbonUI.Invalidate method to refresh the custom UI
See the video, and view the code for more details!
Frequently we come across the question “How do I extend Outlook to do <a task>”. Depending on how extensive the task is, you might look for your answer in one or more of the following ways:
You can browse and get clues from code samples listed in the following locations on MSDN:
There are close to 100 managed code samples listed on this page in the Outlook 2010 Primary Interop Assembly Reference. For example, How to: Create a Meeting Request, Add Recipients, and Specify a Location.
There are many managed code samples in Visual Basic and C# under this folder and its subfolders, that use the Outlook Primary Interop Assembly (PIA), and are part of Office Development in Visual Studio 2010. For example, How to: Perform Actions When an E-Mail Message Is Received.
There are code samples in Visual Basic for Applications and C# listed on this page in the Outlook 2010 Developer Reference. For example, How to: List the Name and Office Location of Each Manager Belonging to an Exchange Distribution List.
You can download the MFCMAPI sample source files to examine example usage cases for many of the MAPI interfaces, as documented in the Outlook 2010 MAPI Reference.
This topic lists sample tasks that use the APIs available in the Microsoft Outlook 2010 Auxiliary Reference.
Often, you can choose to achieve a task by using the Outlook PIA, object model, Messaging API (MAPI), or Outlook Auxiliary API, or, a combination of these APIs. Other than API support and feasibility, there exists other criteria that you should consider when deciding how you should implement a solution. The following questions may come to mind:
· Apart from the goals of the solution, the target market, and available resources, what other criteria should you consider to select the appropriate API?
· If your solution has to run on earlier versions of Outlook, including Outlook 2003, how does that affect your API choice?
· If your solution has to iterate through Outlook folders that contain thousands of items, and you need to be able to modify those items, which API would work best?
· If your solution relies heavily on Outlook business logic and interacts with other Office applications, is the Outlook object model the best choice?
· What do the object model and MAPI allow you to extend in Outlook?
· If you can use either the object model or MAPI to achieve your task, how should you decide which API to use?
· Do you use a managed or unmanaged language, and do you implement the solution in the same thread as Outlook or as a separate thread?
· What’s the level of technical expertise required to use a certain API?
To determine the best API or technology for your solution, you must first define the goals of your solution:
· The versions of Outlook you intend your solution to support.
· The high-priority scenarios of your solution and, in particular, whether these scenarios involve enumerating, filtering, or modifying folders that contain many Outlook items.
Try to match your scenarios with those that the Outlook object model or the PIA supports. Before, this question required combing through the object model. Now you can refer to Decision Factors for the Object Model or PIA which contains a graphical listing of baseline scenarios supported by all versions of Outlook, followed by additional scenarios supported by Outlook 2007 and Outlook 2010. If the object model (or PIA) of your target Outlook versions supports your scenarios, and your solution does not manipulate folders with many items, you should implement your solution as an add-in, in either a managed or unmanaged language.
If the object model (or PIA) of a target Outlook version does not support some of your scenarios, verify whether MAPI or the Auxiliary APIs meet your needs. You can refer to Decision Factors for MAPI or Decision Factors for the Auxiliary APIs. If MAPI meets your needs, you should implement your solution in unmanaged code. If an auxiliary API solves one of your scenarios, you can use managed or unmanaged code.
If your solution uses MAPI, you must implement it in unmanaged code, such as C++. Otherwise, the decision to use managed or unmanaged code to create the solution generally depends on your available resources and their expertise. As for deciding whether to implement the solution as an add-in or standalone application, choose an add-in to avoid the user constantly invoking the Outlook Object Model Guard, unless your scenario requires manipulation of folders that contain numerous items. In the latter scenario, implementing the solution to run as a background thread can optimize Outlook performance.
If your scenarios include showing social network information or updates in Outlook, you should use the Outlook Social Connector provider extensibility to create a COM-visible DLL. You can do this in either a managed or unmanaged language.
Refer to Selecting an API or Technology for Developing Outlook Solutions for an in-depth analysis of how to determine the appropriate API or APIs for your Outlook scenario. Once you have decided on the APIs or technology to use in your solution, you can refer to additional documentation and code samples, as listed in the earlier part of this article.