Question on Named Prop Caching in MFCMAPI

Jan 18, 2010 at 9:00 PM

As of the July 09 release of MFCMAPI, Name Prop Caching was introduced for performance reasons as discussed here:

http://blogs.msdn.com/stephen_griffin/archive/2009/07/16/july-2009-release-of-mfcmapi.aspx

My question is why some 3rd party custom props seem to take time to display as of this release of MFCMAPI?  After refreshing a number of times, property names eventually appear, but never right away... no trend in timing has been identified, but I'm assuming this may have something to do with the introduction of copying property tags to cached memory to cut down on calls made to Exchange.  Is it possible that certain props, perhaps within a certain address range may take more time to copy into cache?  Would the number of props have an effect on this?  (ie.  would one prop take just as long to load as 7?).  This is seen consistently in this release of MFCMAPI only. 

Coordinator
Jan 18, 2010 at 9:09 PM

Caching is immediate - we check the cache for the name, if it's not there, we make the call, cache the result, and return it.

Like I told the previous poster, I need more information on the repro scenario. What is meant by "3rd party" custom props? Are custom message stores involved? Are you using Outlook's MAPI or Exchange's MAPI? What versions? More details please.

Jan 19, 2010 at 7:17 PM

Sorry about that... bad terminology on my part :)... I'm simply referring to Properties within the 0x8000 address space.  So... 'Named Properties'.  There are no 'custom message stores' involved in this 3rd party application.  Strictly a MAPI client utilitizing Exchnage's MAPI subsystem to assign named properties to messages.  Hopefully that's enough detail... if not, please let me know.

So, there are 7 properties that do not immediately show their corresponding 'Named Prop Name' when clicking on a message within the user's message store.  Again, this began in the July 2009 build of MFCMAPI and is still present in the most recent November 2009 build.  When forcing a 'refresh' on the item, 'most' of the seven properties will show up... most of the time :), however, sometimes there will be one property that will never seem to display it's 'Named Prop Name' value.  One thing to take note of here is that 6 out of 7 of these named properties are found in ANSI format.  The one property that does NOT seem to be found in ANSI format, ALWAYS loads right away. 

Now, I know there are measures within the code for MFCMAPI to appropriately handle ANSI data that may be inappropriately stored within a property (to my knowledge, this functionality has been around for quite some time).  However, I notice it is making a similar check for 'ANSI' data within properties when attempting to copy named property data to/from cached memory.  Could this additional check in the 'Named Property Caching' for ANSI data types be what is causing the delay to show the 'Named Props Name' for the properties in question?

Coordinator
Jan 19, 2010 at 7:29 PM
Edited Jan 19, 2010 at 8:02 PM

Ok - so we're talking about RIM's abuse of named props here. I'll see if I've got a PST with some RIM modified messages and check them out. Again - there's no timing going on here, but perhaps my cache lookup is getting confused by the bad data in the prop name.

[edit] Found a message to test with. This problem will only happen with RIM's named props (cause they're the only ones I know of that abuse the names like this). I need some special case code in my lookup to handle them. This will be fixed in the next build.

Jan 20, 2010 at 2:49 PM

This thread interests me. What constitutes 'abuse' of named properties? Is this documented anywhere? I'd like to review any guidelines that exist.

Coordinator
Jan 20, 2010 at 3:08 PM

The name of a named prop is a unicode string. RIM shoves an ANSI string in there. MAPI doesn't reject it cause it's hard to tell that it's not just some bizarre Unicode string, but it breaks a lot of code, especially when the name is an odd number of characters.

Jan 20, 2010 at 6:00 PM

So someone has to explicitly set the type to ANSI when doing that or is there any way that this is a byproduct of making a certain call?

Coordinator
Jan 20, 2010 at 6:17 PM

There's no type to set. They're just putting the wrong kind of data in the structure.

Coordinator
Jan 25, 2010 at 1:46 PM

This is fixed in the January 2010 Release.