Appointment.Occurrences is read-only

[Jim]

I'm working with RadScheduler for Winforms, still working with the 2010_1_10_504 release, and I would like more control of the Occurrences collection of the Appointment object. With Exceptions, there is an Add method. But Occurrences seems to be read-only.

I want finer-grained control of the editing capabilities I have with Occurrences. I've got a custom appointment class, am using a custom appointment factory, custom dialogs for editing appointments and recurrence rules. I am writing Occurrences to their own table, and wish to maintain them myself.

Any tips on how to achieve this objective would be much appreciated. I'm aware that I can override CreateOccurrence, but have still not reached my objective.

Update: all the occurrences of my recurring appointment show up in the scheduler. However, I have apparently not succeeded in building the Occurrences collection for a recurring appointment. The recurrence icon does not show up on the various occurrences within the scheduler.

My main point is that there is an inconsistency in the way one can populate Exceptions and Occurrences. If I could handle both the same way, the coding I'm attempting to do would be easier.

[Dobry Zranchev]

Hi Jim,

Thank you for writing.
 
The idea of the occurrences is to show the appointment in the given range. This means that if the appointment has a Recurrence rule and the active view shows a 5 day range, the view will calculate the occurrences in this range.
 
The meaning of exceptions is to replace some of the available occurrences. The view will show the exception instead of the occurrence if the start date of the exception is the same as the occurrence start date. This is an exception of the rule.

If you have other questions, feel free to write back.
 
Greetings,
Dobry Zranchev
the Telerik team

[Jim]

Well, duh.

[Jim]

Okay, I was put off by your response and responded badly. Sorry.

I have explored exceptions and occurrences, and am not looking for a basic explanation. What I want to do is gain more control so that, for instance, an exception need not be limited to the same start date as the occurrence it replaces. I would also like to be able to delete an occurrence. You can't delete an occurrence by creating an exception for it. You'd have to delete the exception, and then you're back where you started. (There is probably a work-around, or you may prove me wrong. I'm open to that.)

At some future date, I hope you will entrust your consumers to maintain their own occurrence collections. Certainly, for those who are satisfied with what they've got, there would be no reason to do so. But, for the rest of us, it would be welcome relief.

[Jim]

I have not been clear, and so you have concluded that I don't know what I'm doing. That's fair.

MasterEventID associates an exception with a recurring appointment. But it does not uniquely identify the occurrence the exception replaces, unless you make a simplifying assumption. Above, you wrote that an exception replaced an occurrence for the same start date. That is your simplifying assumption.

That's not good enough for what I have to do. I need to be able to identify the occurrence that an exception replaces. So, I evidently need to manage the occurrences myself. If I could do that, I would not be bound by your simplifying assumption.

The Occurrences collection is read-only, so I can't manage it the way I want to. That is the problem. I know you can't change that immediately, but maybe I've expressed myself clearly enough that you know what I'm saying now.

Thanks for your patience!

[Dobry Zranchev]

Hello Jim,

Thank you for writing back.

Let me try to explain how the recurrence rules work in the scheduler.

Let's assume that we have an appointment with a start date of "01/01/2010 10:00"; its duration is one hour; and its recurrence rule is set to show the appointment every other day. Now, if you want to remove an appointment in the series, you would need to add an exception for that appointment. Here are the steps:

1. Add a new appointment, with its Visible property set to false, and RecurrenceId property set to the exact date and time that you want to remove.
2. Add this appointment to the Exceptions collection of the master appointment. Here the RecurrenceId property will verify which date should be manipulated in the recurrence, and if the date and time match, this exception will override the original recurrence. Since its Visible property is false, no appointment will appear in this time slot.

This is the way Microsoft Outlook works, as well.

If you have other questions, feel free to write us.

All the best,
Dobry Zranchev
the Telerik team

[Jim]

Thanks, I appreciate this forum. I've thought about using the visible property, but did not pursue it. The main reason I dismissed it before is that "Visible" is not a column in the Appointments table (per the Telerik RadControls for Winforms Courseware). I supposed that if the Visible property were not persisted that it would not be a lasting fix.

What I infer is that you end up with an exception having the same start and end times as the original occurrence. Somehow, (wink, wink), that is supposed to mean that the occurrence is to be made invisible. Yuck.

This may very well be the way the Outlook works. That's not the highest of endorsements, but I believe it.

Anyway, I'll get on with it. Your solution may be perfect, and all I need to do is go with it.

[Jim]

I have nothing in particular against Outlook. It would have been better had I just stopped writing before I made that remark.

Back to the topic of exceptions and occurrences... I think using the MasterEventID to match an exception with a recurring series of appointments is a good system. But to have the kind of control over occurrences that I want, I would maintain them in their own table. With a Status column, I could set any occurrence to active or inactive. Then I wouldn't have to play around with invisible exceptions, or whatever.

I can't take this level of control over occurrences because the Occurrences collection of the Appointment object is read-only. Therefore, I can't read occurrences from my own table and build the collection. If I could do that, I would have much finer-grained control over recurring sequences. Of course, I could not allow recurring series that go on forever, as no table would hold infinitely many rows. But no recurring series really does go on eternally. Users would have to set a number of occurrences or pick an end date.

If most programmers are happy with the system the way it is, then they won't care that the Occurrences collection is read-only. Changing that won't set them back. It would allow the programmer complete control over the Occurrence collection, which they could take or leave.

[Dobry Zranchev]

Hi revox,

Thank you for writing back.
 
The idea of the occurrences is to represent a recurrent appointment. This occurrences are recalculated every time the visible range is changed. Meanwhile, the decision to store/load the Visible property in the database up to the developer. Some developers do not need to store/load this property and this is the reason why its default value is true. If you need some additional information about appointment exceptions, we will be glad to answer your questions.

Here is the place to explain that our architecture is to recreate occurrences only in the visible time frame of the scheduler. This means that if you navigate to the next date of the active view then the occurrences will be recreateded according to the new time frame. The occurrences are temporary objects and this is the reason why the occurrences collection is read-only. If you want to modify an occurrence, you should create an exception appointment based on it and add this exception to the Exceptions collection of the master appointment.

Feel free to write back in case of further questions.

Regards,
Dobry Zranchev
the Telerik team

[Jim]

Makes sense. I guess if you allow recurring appointments without any end date, then you would have to take some such approach to ensure that the occurrence collection is finite.

[Jim]

Well, we all know that the occurrence collection is finite. Even if you set no end date, there are bounds. But that is just an aside.

I'll tell you what I'm doing in code with regard to occurrences and exceptions.

On reading an appointment from the database, I check for nontrivial recurrence text. If an appointment has a recurrence rule, I loop through the occurrences collection. I do this to determine the date and time of the next occurrence, as this is useful data to our users. Provided an appointment has occurrences, the occurrences collection is available.

I also read in all exceptions for a recurrent appointment. I clear the Exceptions collection and then build it based on the data in my Appointments table. MasterEventID identifies the exceptions.

So, in a layer of the software that is oblivious to the UI, I can loop through the occurrences collection and build the exceptions collection.

What I cannot do is build the occurrences collection. Provided I have the recurrence rule text and the start datetime, in principal I could do so. But the Occurrences collection is read-only, so I am blocked.

That's what I'm doing. I'd like more control. End of story.

Thanks for your response! I may not get what I want, but at least I can vent.

[Dobry Zranchev]

Hi revox,

We already check for the End date of the recurrent appointment, but here is the place to explain that the time frame from start to the end could be too long. This means that we should create too many AppointmentElements, which is a time consuming operation. We will not update this functionality.

Your scenario looks fine. I am happy that you found a solution to work around the default behavior of the scheduler.
 
Sincerely yours,
Dobry Zranchev
the Telerik team