I finally managed to recreate an obscure bug in RadScheduleView. This one deserves a few extra points, I think. :)
Background: We have a custom appointment class which is somewhat data-heavy. Because of this we cannot load up all the data for each appointment when the Appointments collection is populated. Instead we listen to the ShowDialog event to catch when the user brings up an appointment for editing. When that happens we call BeginEdit() and initiate a service call to get the full set of data for the appointment in question. When the service call returns, we populate the appropriate fields on the appointment and call EndEdit().
Now for the bug, which is rather obscure. Here is how to reproduce it in the sample project (link below):
1. Double-click either one of the two appointments in the Month view.
2. Edit the Subject.
3. Bring focus to the Description field, or any other field except the Subject.
4. Bug 1: When the Subject field lost focus, the window header updated immediately. This should not have happened since the appointment had not yet been saved.
5. Click the Cancel button.
6. Double-click the appointment again.
Bug 2: The previous edits that should have been cancelled were in fact not cancelled at all, but remain in place in the edit dialog. However, they were _not_ commited to the Slot in the scheduleview representing the appointment.
Maybe I am doing something wrong here. I am not entirely sure how the whole BeginEdit/EndEdit thing should be handled. But my code looks logical enough to me and I believe it should work. Please advice on possible workarounds.
I am using the internal build from 4 October, but as far as I can see this bug has been present for quite some time. It is only very recently that we found it.
Sample project on dropbox:
http://dl.dropbox.com/u/7890705/ScheduleViewInWindow.zip
Check out the code in the event handler for the ShowDialog event, that is where the interesting stuff happens.
Best regards,
/Henrik
Background: We have a custom appointment class which is somewhat data-heavy. Because of this we cannot load up all the data for each appointment when the Appointments collection is populated. Instead we listen to the ShowDialog event to catch when the user brings up an appointment for editing. When that happens we call BeginEdit() and initiate a service call to get the full set of data for the appointment in question. When the service call returns, we populate the appropriate fields on the appointment and call EndEdit().
Now for the bug, which is rather obscure. Here is how to reproduce it in the sample project (link below):
1. Double-click either one of the two appointments in the Month view.
2. Edit the Subject.
3. Bring focus to the Description field, or any other field except the Subject.
4. Bug 1: When the Subject field lost focus, the window header updated immediately. This should not have happened since the appointment had not yet been saved.
5. Click the Cancel button.
6. Double-click the appointment again.
Bug 2: The previous edits that should have been cancelled were in fact not cancelled at all, but remain in place in the edit dialog. However, they were _not_ commited to the Slot in the scheduleview representing the appointment.
Maybe I am doing something wrong here. I am not entirely sure how the whole BeginEdit/EndEdit thing should be handled. But my code looks logical enough to me and I believe it should work. Please advice on possible workarounds.
I am using the internal build from 4 October, but as far as I can see this bug has been present for quite some time. It is only very recently that we found it.
Sample project on dropbox:
http://dl.dropbox.com/u/7890705/ScheduleViewInWindow.zip
Check out the code in the event handler for the ShowDialog event, that is where the interesting stuff happens.
Best regards,
/Henrik