-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > [EMAIL PROTECTED] wrote: >> A simple example is MAPI named properties. Technically, named properties >> are *optional*. A MAPI message store doesn't need to support named >> properties according to the MAPI documentation. But, if you want to work >> with Outlook calendar entries, todo items, etc., you really *do* need to >> support named properties, etc. Many of the *interesting* Outlook >> properties are undocumented named properties. >> >> If you want Outlook to open your message store and work with it the way >> Outlook works with the Exchange message service, etc., you need to >> implement and support named properties. The MAPI documentation, Inside >> MAPI book, etc. may indicate that a MAPI message store doesn't really >> have >> to do this, but Outlook works the way it works and wants what it wants. >> And, what Outlook expects from a message store is just not documented, >> not >> even in the Inside MAPI book. > that's what I thought first reading your mail. > Studying MAPI I'm understanding how this "standard" has been built: it > has to look like a "standard interface" for leagal issues (monopoly...), > yet it lets a vendor (MS?) implement lots of undocumented features.
Well, you might be right. It could also be symptomatic of big, bloated, upfront design. Enhanced MAPI hasn't changed in about a decade. It's still at 1.0. Too complicated and bloated to change it. It's written on top of ancient C-style COM, not even COM+. > But, excuse my insistence: can you make some example of such > undocumented properties and the Outlook feature they implement? Sure, not a problem. Sorry I wasn't clearer earlier. Outlook asks for a property tag such as: 0x36D00102 I don't believe that this is documented anywhere by Microsoft. This MAPI Property tag consists of an actual ID and a Type. The lower 16 bits (the 0102 part) is the property type. In this case, 0x0102 represents PT_BINARY (byte-string, an SBinary value), basically the type used for MAPI Entry IDs. The upper 16 bits (the 0x36D0 part) is the actual identifier. Outlook expects this to be a Calendar Entry ID. If you don't return the Entry ID for the Calendar folder when MAPI asks for this property, Outlook won't treat your Calendar folder as a Calendar folder. The Inside MAPI documentation may refer to specifying the type of items that are contained within a folder (the PR_MESSAGE_CLASS type), I don't recall off the top of my head. You would set it to "IPM.Appointment" (also undocumented). This type could (should?) also be specified on each entry within the Calendar folder. Until I set all of these properly (and probably a few other magic incantations), I don't believe that my folder truly displayed as a calendar folder containing calendar entries (as opposed to just an email folder containing email entries). Not sure how clear the above is. The named properties are just a bit more complicated than this. This is the level of detail that needs to be understood to work with MAPI properties for reverse engineering. I believe that the same understanding is probably necessary for either "over the wire" reverse engineering for replacing Exchange or for writing code for the MAPI API. > thanks a lot > Luca Hope this helps, Jason Nocks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB9t3B3CryLfCgqRkRAvbzAJ4/nN8wyoIPrn0MOLOI/gxyGqZdhgCeOLcI J8Thkf33QS+lU223q3naHEc= =OxsA -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ otlkcon-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
