Accept or Decline Meeting Request programmatically with MAPI?

[fbs]

I don't seem to see any APIs in the MAPI SDK for responding to a
meeting request, and I haven't seen any postings on this subject. Do
you just send a reply with certain flags set? How do you designate
Accept, Tentative, or Decline?

Thanks

[Dmitry Streblechenko]

MAPI knows nothing about meeting requests, but Outlook object model does. All
the required properties are undocumented named properties, look at the messages
created by Outlook with MdbView or OutlookSpy, also see
http://www.cdolive.com/cdo10.htm for the list of most properties.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"fbs" <fsi...@seven.com> wrote in message
news:fd8ba9a5.02012...@posting.google.com...

[fbs]

Looks like there are a few properties that need updating:

0x8218 -- response status
0x8205 -- "busy" status -- blue if accepted, light blue if tentative,
etc.
PR_LAST_MODIFICATION_TIME
Also probably have to mess with free busy stuff since I'm getting
conflict messages.

I wondering -- it looks like these properties don't really do anything
with the message. Is it up to me to do mapi calls to send the
response? Also, in the case of decline, is it up to me to delete
these messages from the calendar and inbox?

Thanks

"Dmitry Streblechenko" <dmi...@dimastr.com> wrote in message news:<eA954VqpBHA.1804@tkmsftngp02>...

[Dmitry Streblechenko]

yes, it will be your responsibility - MAPI knows nothing about meeting
requests/responses. To MAPI they are just messages, nothing more.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"fbs" <fsi...@seven.com> wrote in message

news:fd8ba9a5.02021...@posting.google.com...

[fbs]

In Outlook, when a meeting request comes in, there is an entry in the
inbox, and an entry in the calendar that is tentative. These entries
have different PR_ENTRYIDs. I'm updating 3 properties: 0x8218
(response status), 0x8205 (busy status), and 0x8220 (the time of the
response). Up until now, I've been doing this for the Calendar
message (PR_ENTRYID of the Calendar entry), and I can see in Outlook
that things change correctly [I can double click and it gives me the
proper status and the time I did it]. However, I'll really be getting
the PR_ENTRYID of the Inbox entry. Using the Inbox PR_ENTRY_ID, I
open this message and change these properties on it, but of course, I
don't see it reflected in the calendar entry since it's a different
message. I've looked in Outlook Spy for a link between these 2, but I
can't find one. Given the Inbox message, how do I locate the Calendar
message? Also, even when I update these properties in the Inbox
message, when I double click on it in Outlook, it still says "Please
Respond". When I do it for Calendar entries, it displays that I have
accepted (or whatever) at the proper time. Any ideas?

"Dmitry Streblechenko" <dmi...@dimastr.com> wrote in message news:<#ILpDGjuBHA.2836@tkmsftngp05>...

[Daniel Mitchell [MVP]]

fsi...@seven.com (fbs) wrote in
news:fd8ba9a5.02022...@posting.google.com:

> In Outlook, when a meeting request comes in, there is an entry in the
> inbox, and an entry in the calendar that is tentative.

First thing -- there isn't an entry in the calendar immediately. Outlook
doesn't create it until you open the meeting request, or possibly after
some time has passed. (at a guess, the same sort of timer-that-needs-
waking-up stuff as with task requests).

> These entries
> have different PR_ENTRYIDs. I'm updating 3 properties: 0x8218
> (response status), 0x8205 (busy status), and 0x8220 (the time of the
> response).

Presumably these are the names of the properties, not the IDs?

> I've looked in Outlook Spy for a link between these 2, but I
> can't find one.

There's two binary properties on the entry in the calendar and the one in
the inbox that are identical (to each other, and between messages).
Checking, it the usual one with ID=3, propsetID=
6ed8da90450b101b98da00aa003f1305; not one of the ones from CDOLive. (though
it has the comedy value of playing spot-the-MAC-address. If I remember
correctly, the guy that wrote that bit of Outlook probably had a 3Com
network card at the time).

What were you looking for when you used OutlookSpy, just out of curiosity?
The property here pretty much leaps out at me -- binary data, named
property, identical on them both; quick cross-check against other meetings,
and it doesn't match up there. This stuff isn't that difficult to find,
honestly.

> Given the Inbox message, how do I locate the Calendar
> message?

Search the calendar for the one that matches this link property.

> Also, even when I update these properties in the Inbox
> message, when I double click on it in Outlook, it still says "Please
> Respond". When I do it for Calendar entries, it displays that I have
> accepted (or whatever) at the proper time. Any ideas?

You're not setting enough properties. Write a little advise sink app (see
docs for IAdviseSink) that watches changes to your mailbox, send a meeting
request with outlook, accept it, and see what's changed. Don't forget to
make the advise stuff dump attachments as well; that's how I got task
requests sorted out.

Again, most of this isn't that difficult once I finally sat down and wrote
the code; morning to write the advise sink, afternoon playing with Outlook
to have a decent set of test cases to look at, next couple of days filling
in properties by trial and error until it worked.

-- dan

[fbs]

I did get this working -- thanks for the help. Using the link props,
I search the calendar to come up with the right entry. I guess I just
missed those link properties -- I was looking for an ENTRYID type
thing. It is interesting that there are 2 properties. One of them
(ID 3) would not be found by the GetNamesFromIds. The other one
(0x0023) is found, so I use that one. Not sure why that would be, and
what the differences are between those 2 props. Also, I was wondering
why some named props have IDs like 8205, 8235, etc., with GUIDs
starting with 0006, and others have low ids like 3 and 23, with GUIDs
starting with 6. Just curious.

Also, I did notice that the Calendar entry is created every time,
whether or not you open the meeting request, but it sometimes takes 30
seconds or a minute. I wonder what people do when the entry is not
there yet -- do they sleep for awhile, and keep retrying?

Anyway -- thanks again for the help. fbs

"Daniel Mitchell [MVP]" <djmit...@yahoo.com> wrote in message news:<Xns91BC9F5428EEDd...@207.46.230.185>...

[Daniel Mitchell [MVP]]

fsi...@seven.com (fbs) wrote in
news:fd8ba9a5.02022...@posting.google.com:

> It is interesting that there are 2 properties. One of them
> (ID 3) would not be found by the GetNamesFromIds. The other one
> (0x0023) is found, so I use that one. Not sure why that would be, and
> what the differences are between those 2 props.

Yeah, I never worked that out either; they always seemed to be the same,
though, so I just used whichever one I happened to code up first.

> Also, I was wondering
> why some named props have IDs like 8205, 8235, etc., with GUIDs
> starting with 0006, and others have low ids like 3 and 23, with GUIDs
> starting with 6. Just curious.

It looks something like the ones with the high IDs are 'user-friendly'
ones (start time, recurrence pattern, etc), but the low IDs are 'internal'
ones (link properties). Why this is, no idea..

> Also, I did notice that the Calendar entry is created every time,
> whether or not you open the meeting request, but it sometimes takes 30
> seconds or a minute. I wonder what people do when the entry is not
> there yet -- do they sleep for awhile, and keep retrying?

I'm not sure -- when I was doing this stuff for task requests, I noticed
that once Outlook's 'noticed' that it should create the second version of
these things (tasks in task folder/tentative appointments) it'll create
them quickly from then onwards, but the first time through it might take a
while to do it. After some time passes, it stops 'noticing' and goes back
to being slow, but if you send a bunch of task requests close enough
together, they all get the associated thing created pretty much instantly.

I have no idea how to get Outlook into 'notices things fast' mode, but
that said, it does exactly the same thing at the recipient end if you send
meeting requsts/task requests from _Outlook_, so I'm not too worried.

-- dan

[fbs]

"Daniel Mitchell [MVP]" <djmit...@yahoo.com> wrote in message news:<Xns91C16C3EDDFB7d...@207.46.230.185>...

Yeah -- I wish there was some way to force it into 'notices things
fast' mode. I'll just have to throw an exception if the entry is not
there yet, and tell people to check back in a minute or 2.

Another question: Is there a property or some way to tell if you're
getting an update to a meeting request? I know you can't rely on the
subject. If someone sends an update where some field like the
location, time, or body is changed, I need to update that
corresponding calendar entry (gotten by 0x0023). I'd rather not have
to update the appointment unless it's absolutely necessary, so I'd
like to tell from that inbox message that it is an update to a meeting
request or not.

Also, is there a way to tell if an update to a recurring appt is an
update to the whole series, or just one appointment?

[Daniel Mitchell [MVP]]

fsi...@seven.com (fbs) wrote in
news:fd8ba9a5.02031...@posting.google.com:

> Another question: Is there a property or some way to tell if you're
> getting an update to a meeting request? I know you can't rely on the
> subject. If someone sends an update where some field like the
> location, time, or body is changed, I need to update that
> corresponding calendar entry (gotten by 0x0023). I'd rather not have
> to update the appointment unless it's absolutely necessary, so I'd
> like to tell from that inbox message that it is an update to a meeting
> request or not.

I'm not quite sure what you're getting at by 'update a meeting
_request_' -- do you mean an update to a request that's still in the inbox?

And surely any time there's an update coming in you'll have to change the
entry in the calendar, because Outlook won't send updates unless there's a
good reason for it?

-- dan

[Dmitry Streblechenko]

Are passing the right GUID?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"fbs" <fsi...@seven.com> wrote in message

news:fd8ba9a5.02031...@posting.google.com...

> "Daniel Mitchell [MVP]" <djmit...@yahoo.com> wrote in message

news:<Xns91C16C3EDDFB7d...@207.46.230.185>...

> When I call our GetNamedProp method using 0x000A, PT_BOOLEAN, it
> doesn't crash, but comes back with some property that doesn't exist.
> It's kind of in the right range for my outlook (80b2000b), and it got
> the boolean (000b) right, but it's not the right prop. How can I find
> whether a recurring appt is being updated? Is there something weird
> with IDs this low (000A)? 0023 worked for the calendar/inbox link
> property.

[Daniel Mitchell [MVP]]

fsi...@seven.com (fbs) wrote in
news:fd8ba9a5.02031...@posting.google.com:

> How can I find
> whether a recurring appt is being updated?

Honestly, I have no idea. As I said, I gave up on all this stuff once we
shuffled our requirements far enough that we can use CDO -- you've got
further into it than I ever did. All I can suggest is what you're already
doing; look at the properties on different types of update request and see
if you can spot a pattern.

-- dan

[fbs]

Actually, I managed to figure out the update stuff. If it's an update
to an instance of a recurring appointment, the 0x8223 (isrecurring)
property will be true in the calendar and false in the inbox. For a
series, it will be true in both.

I have one problem left. I use that 0x0023 property for the link
between the calendar and the inbox entries (there is also 0x0003, but
that doesn't work for me). On most machines this works, but on at
least one machine, after the HrQueryAllRows, we never go through the
case for that property tag, i.e.

HrQueryAllRows
for (i=0; i<pRow->cRows; i++) {
for (j=0; j<pRow->aRow[i].cValues; j++) {
set the tag
switch (tag) {
case PR_ENTRYID: blah blah
case PR_CAL_MREQ_LINK: blah blah -- never gets here

So I can never get the corresponding calendar entry.

I've tried both the 0003 and the 00023 properties, and it doesn't hit
either of them. Have you known this to happen -- are these properties
reliable -- and do you know of a workaround?

Also, I would love to know a way to force Outlook into 'fast' mode for
putting in the linked calendar entry. I wonder why when you double
click the inbox message, it puts it in to the calendar immediately?

This stuff is really nasty.

[Daniel Mitchell [MVP]]

fsi...@seven.com (fbs) wrote in news:fd8ba9a5.0203151726.5d331412
@posting.google.com:

> I have one problem left. I use that 0x0023 property for the link
> between the calendar and the inbox entries (there is also 0x0003, but
> that doesn't work for me). On most machines this works, but on at
> least one machine, after the HrQueryAllRows, we never go through the
> case for that property tag, i.e.

Probably a dumb question, but are you doing a SetColumns() on the table
first to make sure it'll contain the columns you want?

> Also, I would love to know a way to force Outlook into 'fast' mode for
> putting in the linked calendar entry. I wonder why when you double
> click the inbox message, it puts it in to the calendar immediately?

Not sure, that lot all felt like some sort of hack someone at MS had put
into Outlook to get around some weird behaviour. The only way I can think
of to force it to do this stuff by hand would be to do some sort of
outlook automation stuff on it and hope that that triggers whatever
internal state's changed, but that's not exactly practical.

>This stuff is really nasty.

No kidding.. I'm impressed by your persistence!

-- dan

[fbs]

I deleted a couple of my posts, so perhaps you didn't see that message
11 in this thread is later (3/15@17:26) than your replies. Anyway --
I guess instead of using the calendar link property (0003 or 0023), I
could just search on calendar entries with the same subject and date
as the inbox entry. Probably slow, but if those properties don't
work, that's probably all I've got. fbs