ItemRemove event not fire when delete recurring appointment

[Jason]

Symptom:
When deleting an entire appointment series, the ItemRemove event always
fires. - That is correct.

When deleting the 1st item from a recurring appointment series, the
ItemRemove event does fire. - That is correct.

However, when deleting the other items (2nd to the last) from a recurring
appointment series, the ItemRemove event does not fire. Instead, ItemChange
event is fired. It does not matter if the 1st item has been removed or not.

Question:
In ItemChange event handler, how to detect that the event is actually an
ItemRemove, not ItemChange?

In the Outlook.RecurrencePattern.Exception collection, the Deleted property
is true for all objects in it, when doing delete and update. Can't see
difference between delete and update. What are the real flags/identifiers?

 

[Ken Slovak - [MVP - Outlook]]

I can't repro this.

If I change the start time of an item in a recurring series it is in
Exceptions, but it does not show Deleted == true.

I set up a series of appointments, 10 in all, and deleted the first 3. I
then modified another instance for start time. In Exceptions I had 3 marked
as Deleted == true, 1 as Deleted == false, exactly what I would have
expected.

 

[Jason]

You are right Ken.

The deleted items remain in the Exception collection and have the deleted
property set to true and the Appointment set to null.

The Exception collection contains both modified and deleted items.

With these knowledge, I am still not able to identify which item is being
modified or deleted, and what operation (modification or deletion) is
performed? And worse yet, does the operation apply on the entire series or
just single occurrence?

The Appointment.EntryId is used for the entire series.
NO properties of the Exception object is useful.

 

[Ken Slovak - [MVP - Outlook]]

Exception.AppointmentItem and Exception.OriginalDate give you enough
information so you can see which instance was modified/deleted in the
Exceptions collection.

For example, get the Start of the item passed to you in ItemChange() and
compare that to each Exception.OriginalDate in the Exceptions collection.

Exception.AppointmentItem will give you back the recurring instance,
although it's not valid for deleted instances.

 

[Jason]

I need to know what is happening right now, not the past history. I need
current item and current action. Look like they are not there. I'd have to
give up on this.

When an item is changed, the original date will be persisted into Exception
object. When another item is modified, there will be another Exception
object with original date. How do we know which is the newest item modified,
or deleted?

Going through Exceptions collection could be time consuming.

 

[Ken Slovak - [MVP - Outlook]]

I fail to see a problem. Iterating Exceptions is not a big deal, nor is
getting recurring instances if you know the start date of the instance or
are incrementing your iteration of the recurrences collection. I do that in
code for a number of my applications. When you get the event you have the
item being changed, it's not a big deal to match it to something in
Exceptions.

If an item is deleted you can't get AppointmentItem for it, if not deleted
you can get AppointmentItem and then check for LastModifiedTime if you want
to see when the Exception was modified.

 

[Jason]

Let me clarify again. I need to be able to identify the item that was
modified or deleted, in other words, I need the ID of single occurrence,
otherwise I can not sync it with other applications. Unfortunately, the ID
is not there. EntryID is just for the whole series. There is no ID for each
occurrence. (ID may be hidden) There is no way to know which item was
modified or deleted. Although it does not matter to work on Outlook itself
as you have done, there is no way to sync Outlook's single occurence with
other application. We can only fall back, treating recurrence as a whole.

In addition to this limitation, Outlook's recurrence design also has another
big problem.

 

[Ken Slovak - [MVP - Outlook]]

Recurrences do not exist as independent instances of an appointment. They
only exist as calculations based on the master appointment's
RecurrencePattern. The Exceptions collection contains those calculated
instances that were modified or deleted. That's the way it is and has been
since Schedule+, it cannot be changed without breaking all existing
recurring items and recurrence code.

Based on the information in this thread you should be able to identify which
occurrences were modified, which were deleted and which have the original
settings. It takes work to do that but that's life. That you can't get an
individual EntryID is due to the nature of the design but hasn't handicapped
other developers working with recurrences.

What you want does not exist. Therefore you either can't do what you want,
must change how you synch or come up with some other workaround.

There are many problems with the existing implementation, but again that's
not changing.

 

[Jason]

I realized the Original time of Exception object can be used as ID. It is
different/unique for each Exception. In a series, each occurrence's start
time is different/unique. It is calculated based on the series start date
time, adding up time difference.

Adding an ID property to Exception object will not break any thing.
Microsoft should do it.
The ID can have already been used as the key of the Exception object in the
Exceptions collection. It is just not yet exposed.

Anyway I gave up. Anything leads to messy code is not worth of
implementation. It will cost you far more than initial creation. The cost of
product maintenance, and the cost of user learning and using the product,
get scary down the road.

 

[Ken Slovak - [MVP - Outlook]]

Since the object references and properties of members of the Exceptions
collection are held in the RecurrencePattern there's no way to add anything
to that without breaking the existing RecurrencePattern and any code that
references or works with it. Until MS completely redoes that at some point
in time, if ever, there's no way to do what you suggest.

I still don't understand the problem. Yes the code to work with
RecurrencePattern and recurrences can get complicated, but once written it's
done and requires almost no maintenance. I have been working with that and
with recurrences in my Reminder Manager addin for more than 6 years now. It
definitely can be done, and I know of many other applications that do it.

Whether or not it's justified for you is another matter.