In Outlook 2013, we took a change to improve how we build search folders when searching against Exchange 2010 and higher for text we’d expect to find in commonly indexed fields. Prior to this change, we’d build a search folder restriction that looks like this:
PR_SUBJECT contains 'text' || PR_BODY contains 'text' || PR_SENDER_NAME contains ‘text' || ...
If you use Outlook 2013 and create an online search folder (say, by just doing a search), then look in MFCMAPI, you’ll find the search criteria is greatly simplified:
0x0eaf001f contains ‘text’
Development has allowed me to document this property:
#define PR_SEARCH_ALL_INDEXED_PROPS_W PROP_TAG(PT_UNICODE, 0x0EAF)
Use of this property in building your searches has a few benefits:
This property will work against Exchange 2010 and higher.
Outlook likes to sort folders alphabetically. When Outlook 2010 came out, some of our custom store provider developers came to us and asked that Outlook not sort the folders they returned. So we gave them a way to advertise to Outlook that the order they returned is the order Outlook should use. However, we didn’t port this fix to Outlook 2013. Why? Because in Outlook 2013 we already had a new feature which allows users to reorder their folders however they like and Outlook would remember the order. The missing piece of the puzzle is to document how Outlook remembers this order so store providers can give a default to their liking.
The key property is PR_SORT_POSITION. Here’s the definition:
#define PR_SORT_POSITION PROP_TAG( PT_BINARY, 0x3020)
Outlook will use this property as part of it’s sort order when requesting folders from a provider, so it’s important that your provider can handle sorting on a binary property – or can fake it when asked to sort by this property. Outlook will also use this property directly when deciding where to insert nodes in the visible tree, so it’s also important that your provider can return this property when Outlook looks for it on a folder.
If you look at some folders with MFCMAPI, you’ll see that Outlook usually only puts only a single byte into this property. Outlook will look at the first byte of this property to do the first pass of the sort. If two folders have the same first byte, Outlook looks at the second byte to break the tie, and so on. You can watch these values change as you continually drag the bottom folder of a list to the top and watch as eventually Outlook has assigned multiple folders a first byte of 00 and has to move to the second byte to break the tie,
There’s a second property Outlook will use for custom sort ordering:
#define PR_SORT_PARENTID PROP_TAG( PT_BINARY, 0x3021)
As the name suggests, this property stores an entry ID which can be used to sort a folder under a different node than it’s natural parent. Normally, a folder will be sorted under the folder represented by PR_PARENT_ENTRYID. This property allows you to suggest a different parent for display.
By presetting these properties appropriately, you can direct Outlook in how you wish your provider’s folders to be sorted. And if you allow Outlook to write to these properties, you can preserve whatever sort order your users desire.