Recurring Calendar Events

[cmury]

All,

I'm looking at integrating recurring events into a calendar. I think this can be done in 2 ways:

1 - Using a repeating field in the calendar data that lists each occurence. This could be achieved through calcs [complex] and the field would the basis for the relationships with the calandar portals

2 - Or perhaps create a second table that lists the occurrences based on the event id. I imagine this would be a messy solution particulary when modifications are made to the recurrences.

Basicially I wondering if anyone has had experience with this and can share the fundamentals behind this concept.

Thanks in advance

C

[transpower]

There are many commercial programs for showing calendar events, such as FMC-Calendar (www.datavations.com). Take a look at these first; if you don't like any of them, then you can "roll your own", but at least you'll have some more ideas.

[comment]

The basic idea, I think, is this:

Left-side key:

Dec-01-2004

Dec-01

01

Wednesday

Right-side keys:

For a regular, one-time event:

Dec-01-2004

For an event that repeats every year:

Dec-01

For an event that repeats every month:

01

For an event that repeats every week:

Wednesday

You need to get more creative for events that repeat every third Sunday of April, for example, but that's the fundamental concept.

[cmury]

Thanks - thats exactly what I was looking for!

I'm guessing you can then control the duration [no. of repeats] of the recurring events by correctly defining the relationship between your keyfields ie the relationship exists for events after the first occurance and before the last.

C

[comment]

Ah, I thought we were talking about perpetual events.

If an event is NOT perpetual, we need to generate a key containing a list of the actual dates (as text, naturally). This can be done either by a script, or by calculation.

In a script you would generate succesive dates in a loop, until you have the required number of occurences.

In a calculation... well, it depends, but I believe the common method is to calculate a rather large number of occurences (i.e. more than the developer expects that will ever be needed), then trim the excess according to actual number of occurences as specified by the user. For example:

LeftValues (**calculation to produce a list of 50 dates** ; XtimesField)

and the user is restricted to a maximum value of 50 in the XtimesField.

The script method has another advantage: since it generates the contents of a regular text field, it is possible to revise the list at any time. For example, we could have a script that locates a particular occurence and deletes it, or moves it to another date.

[comment]

Oops! I've been guilty of both thinking in pre-version 7 terms AND not reading your remark carefully enough!

Interesting concept: you would define an event as perpetual, e.g. every Wednesday, then set StartDate and EndDate. Then you set up a multi-criteria relationship, so that the CalendarDate is Wednesday AND falls within the range. Wow! It's not as controllable as a list of dates, but it beats the calc method hands down. Great idea, thanks!

[cmury]

Comment

Yes - I think this conecept is a neat method which exploits the new relationship model of FM7. Also the removal of the calc fields may make things run a bit smoother.

As you suggest this method will only produce a set series of events. The user will be able to control the start, end and frequency of the series - but not individul events in the series. I guess this will be fine in most circumstances and VERY easy to set up.

If more control is required then perhaps it may be worth setting up a new table for recurrences of each event. One way could be that a calendar event in one table has a relationship to multiple records in another table based on an ID. The series would have to be created/deleted using script but individual events could be editable through a portal arrangement. Again limited amount of calcs & repeats involved.

Well time to put this into practice. Let me know if you have any further ideas.

Thanks

C

[comment]

1.

I don't think having another table for events that are more complex is a good idea. Suppose you want to switch an existing event into "complex mode". You'd need to shuffle the record to another table.

You could add a field named Complex (number, auto-enter 0) to Events. In the Calendar table, create a calc field, called constant1 (= 1). Then the "simple" relationship will have another criterion, that is constant1 <> Complex. Now to switch the Event to "complex mode" simply toggle the Complex field to 1.

2.

There's no need for multiple records for a complex event (think of the hassle of renaming an event, for example). Just put all the occurences in a multi-line key. The key can be easily manipulated using text functions.

3.

There's the amount of relationships to consider. My very simple Calendar (from ver. 4) has 7 reationships to Events, one for each day of the week. I'd need to add 7 relationships for every new type of event.