[This is now documented here: http://msdn.microsoft.com/en-us/library/ee201126(EXCHG.80).aspx ]
Those of you wrapping PSTs may see something interesting in the restrictions Outlook 2007 will try to set against your folders. There are a couple of new restriction types you won't have seen before. Outlook will only use these restriction types when it's working with stores it knows supports them (like a PST), so in general you can ignore them and just pass the restriction on to the underlying store. However, if you're trying to make a copy of the restriction structure for some later use, then you need to know what they look like in memory.
Here are the definitions of the two new restriction types:
#define RES_COUNT ((ULONG) 0x0000000B)
#define RES_ANNOTATION ((ULONG) 0x0000000C)
The layout in memory of the associated restrictions is the same as some existing types, which should make parsing them for the purposes of copying easier. RES_COUNT is identical to RES_NOT and RES_ANNOTATION is identical to RES_COMMENT, so to copy a restriction of type RES_COUNT, you can use the resNot member of the union, and for RES_ANNOTATION you can use the resComment member. As an example, we look at how we would fix up MFCMAPI's HrCopyRestrictionArray function. We can take advantage of our existing code by just adding the new cases to the switch. This works since the structures involved are identical:
LPSRestriction lpResSrc, // source restriction
The next update to MFCMAPI will have these changes (and more) in it.
What happens if I try to use the RES_COUNT restriction?
I would imagine it won't be valid in IMAPITable::FindRow(), only in IMAPITable::Restrict(), right?
I am going to get back a single row with a single PRopValue.Value.l being the number of items?
We're not at this time documenting what these restrictions are used for.
Well, the restriction certainly works in IMAPITable::Restrict (S_OK is returned), but IMAPITable::QueryRows returns the regular row set...
The April 2008 Release (build 18.104.22.1685) is live: http://www.codeplex.com/MFCMAPI Here's the change
Wrapped PST and Free busy provider seem incompatible in Outlook 2003. For calendar event created in wrapped PST store, free busy provider doesnt get loaded. It gets loaded fine in case of 2007. Also changing the line:
*ppMDB = lpPSTMDB;//pWrappedMDB;
gets the Free busy provider loaded. I am lost at how to get it working. Any help would be appreciated.