Hello, i work on an old Project with VS2008; .Net 2.x and Infragistics 8.2 (not possible to upgrade the Project at the Moment!). I use the calender info and fill the appointments and owner structure via dataset from a SQL Server 2008 R2 database. I store my additional Infos i Need in a csv-list in the datakey and handle additional Relations on the database via stored procs, that proof on insert, update and delete what to do. So if i have a appointment on a day for several 'owner', my sp handels this on the database and i also catch the 'close' of the appointment Dialog to create the additional appointments in the calender info collection. This works fine for me. But i have a Problem with this if the appointment should be a recurrence!
My wish: take the reccurence-pattern (ex. 10 daily recurrence) and create 10 appointments in the database with a flag that they belong to a 'reccurence' and a relations-table for this recurrende (say rec 1).
But how Looks the structure i must build, if i create my appointment-collection from the database?
I never load all appointments, so I mostly don't load the root appointment!
What is the best way to use the Recurrence2003 Dialog with all the work infragistcs allready done?
Should i sign each appointment-recurence as variance?
Thanks
Patric
Hi Patric,
The recurrences are built each time, not stored separately. And the recurrence information should come from the root appointment.
Hi Michael,
one last question:
If i Close the reccurence-Dialog it create a reccurrence-object for the appointment and the appointment belong to the appointment-collection of the calenderInfo-object (so i can bound the same collection to week-view, day-view, ...). In the views i see the appointments of the collection and also the (new) reccurring appointments but the reccurring appointments are not part of the appointment-collection!
Where hold the calenderInfo the reccurring-appointments? Or are they build each time by the 'Reccurring-engine'?
Last question, i promise.
I think that given the scenario, this sounds like a suitable workaround to try.
Since you already store the additional information in the datakey, you may as well utilize it where you can.
Let us know how it turns out for you!
my idea is a Little different. Since i don't Need the whole functionality of the reccurrence appointment (i only Need the Dialog for the mass-Generation of the same appointment with different Dates and a fixed end-date), i will 'Hook' on the 'OK' Button of the 'Reccurrence-Dialog' and catch the Pattern of the reccurrenc (daily, weekly monthly; the occurence [x-time, ...] and the end-date or number of reccurrences). Then i calculate the appointments in the database as 'Appointments' and as 'Members that belong to a reccurrence' (simple table with two keys!). After the Dialog is closed, i reload the appointments for the calender info.
In the calender info i catch the 'BeforeAppointmentChange' Event and check, if this is part of a 'Reccurrence-Collection' (i have my own flag in the DataKey') i Show a Dialog where the user can select
1. 'Change only this appointment' --> no longer member of the Reccurence-Colection so delete the entry in the relation table and the hint in the DataKey and open the Appointment-Dialog
2. Delete the whole Reccurence-Collection --> delete each entry in the relation table and the corresponding appointment(s)
Since i don't store the reccurence rule, the user can't Change the reccurrece patern and Regenerate all the appointments (for this he must delete the old one and create a new one). So i don't Need to know how to build a recurrence object and init the Dialog with an existing structure! I always build a new one.
I know, it's a Little dirty.
Do you think it's too dirty?
I think the best course you could take is to actually compile our source code. This would allow you to stick breakpoints in it and debug along to follow the code's flow.
After taking a quick look at our code, I would probably start by placing a breakpoint somewhere in the Appointment's constructor. That way I could see where each instance of an Appointment is actually created.