Share via


New Restriction Types Seen In Wrapped PSTs

[This is now documented here: https://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:

 HRESULT HrCopyRestrictionArray(
   LPSRestriction lpResSrc, // source restriction
...
   )
{
...
       switch (lpResSrc[i].rt)
     {
...
        case RES_NOT:
       case RES_COUNT:
         if (lpResSrc[i].res.resNot.lpRes)
           {
...
        case RES_COMMENT:
       case RES_ANNOTATION:
            if (lpResSrc[i].res.resComment.lpRes)
           {
...

The next update to MFCMAPI will have these changes (and more) in it.

Comments

  • Anonymous
    April 01, 2008
    Steve, 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? Thanks!

  • Anonymous
    April 01, 2008
    We're not at this time documenting what these restrictions are used for.

  • Anonymous
    April 02, 2008
    Well, the restriction certainly works in IMAPITable::Restrict (S_OK is returned), but IMAPITable::QueryRows returns the regular row set...

  • Anonymous
    April 03, 2008
    The April 2008 Release (build 6.0.0.1005) is live: http://www.codeplex.com/MFCMAPI Here's the change

  • Anonymous
    September 18, 2008
    The comment has been removed