If anyone 

a:wants to write code to accept meeting requests, and
b:needs to have named properties in calendar items, 

this is what you need to know.

1. Just accepting meeting requests/cancellations is relatively easy; call
GetAssociatedAppointment(), Update() on that appointment, voila. 

2. Doing reschedules is a big pain.

If you call GetAssociatedAppointment() on a meeting reschedule request,
it deletes the meeting in your calendar and creates a new one. (this is
documented, it turns out; I was wrong beforehand. Quoting from the
docs for GetAssociatedAppointment(): 

If the meeting's organizer has sent an updated meeting request since you 
accepted the first request, CDO considers the existing AppointmentItem 
object in your calender folder to be out of date. When you call 
GetAssociatedAppointment, the existing appointment is deleted from your 
calendar folder, and GetAssociatedAppointment returns a new, updated 
AppointmentItem object. However, this new appointment is not stored in your 
calendar folder until you call its Update method. 

 This delete-and-recreate process doesn't preserve any named properties you
may have put on the meeting, of course.

 [as a side note, Outlook _does_ preserve named properties when you accept
 things using it]

So the solution is to read any named properties you care about from the
meeting in your calendar, _then_ call GetAssociatedAppointment, then 
put those named properties back.

But how do you get at the corresponding meeting in your calendar without
calling GetAssociatedAppointment?

Well...

In propset 6ed8da90 450b 101b 98da00aa003f1305, property IID=35, there's
a binary property. (weird propset -- I think you could probably work
out who wrote this bit of CDO/Outlook, because those last bytes are
a MAC address if ever I've seen one.. Oh, and that's a real propset, not
a CDO-munged one, so you'll need to byteswap as per usual if you want
to use this in CDO. I'm not sure how to turn IIDs under 0x8000 into the
CDO-formatted strings, I'll admit; a bit of trying and I gave up and
went back to raw MAPI to do this).

This property is the same on the meeting reschedule request in your inbox
as it is on the meeting in your calendar. You can thus use this with
a bit of filtering (and, for a nice change, filtering works here) to
locate the meeting in your calendar, read properties out, all is well.

 [as another side note, the Exchange SDK helper function HrMAPIFindMsgByProp
 is broken, and infinite-loops if if finds any messages. It's easy enough
 to fix, and the source is in the platform SDK, thank heavens, but this is 
 a little warning to save anyone else waiting and waiting and waiting and
 wondering why things are so slow..]


So the next question, of course, is what happens with recurring meetings?

Well, as we all know, recurring meeting instances are stored as attachments
to the base meeting; get from an instance to the base meeting by going
GetRecurrencePattern() and Parent() on the pattern, loop over the attachments,
property 0x7ffc, time, is the start time of that instance, in _local_ time
(ie not UTC as all other MAPI stuff would have it).

Looking through a meeting reschedule request, though, we find a lot of 
properties which are for the _new_ time of the meeting -- but none for
the original time before the reschedule -- so how do we know which meeting 
instance to open up?

In the same propset as before, IID=3, there's another binary property.
Bytes 17-20 of this property are an encoding of the date of the original
date of this recurrence instance; call them A B C D for 17,18,19,20
A*256+B = year, C = month, D = day.
We can then turn that into a time, search the list of attachments to see
if any of them match up with this time (remembering that the attachment
property for time does contain time-of-day info so you can't just do
CompareFileTime, you have to manually compare year/month/day) and then
get the relevant attachment -- open the attachment as a message, blah
blah blah, all is well.


 Note: you can't have Outlook running during this stuff. If you do, then
 Outlook tentatively accepts the reschedule or somesuch nasty thing, which
 alters the attachment table, which means your code can't locate the
 original instance any more.



Anyway. That's the fruits of the last few days of my life, dumped out here
in case anyone else ever needs to know this stuff..

 -- dan