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?

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Jason" wrote in message
...
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?

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]" wrote in message
...
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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Jason" wrote in message
...
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?

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Jason" wrote in message
...
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.

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]" wrote in message
...
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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Jason" wrote in message
...
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.

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Jason" wrote in message
...
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.

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]" wrote in message
...
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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Jason" wrote in message
...
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.

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Jason" wrote in message
...
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.

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]" wrote in message
...
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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Jason" wrote in message
...
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.

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Jason" wrote in message
...
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.