Hello,
We seem to have discovered what we think is a bug in RadScheduler when dragging events in the MonthView (haven't tried it on other views). Taking the code below, we are able to capture the modified appointment upon dragging.
What we have found is that when the right end of an event (which spans more than one day) is dragged to shorten the event, the date in modifiedAppointment.End is incorrect.
protected void radScheduler_OnAppointmentUpdate(object sender, AppointmentUpdateEventArgs e) {
var modifiedAppointment = e.ModifiedAppointment;
}
For example, we have an event which correctly displays as starting on 21/12/2016 at 09:00AM and finishing on 23/12/2016 at 12:00PM (midday).
This displays correctly on screen with a bar occupying 21, 22 and 23 December 2016.
If we use the mouse to drag the right end in by one day, modifiedAppointment.End holds 23/12/2016 12:00AM. This occurs even when the mouse is to the left of the day boundary line.
We believe that it should hold 22/12/2016 12:00PM, ie decrease the date but one day, but keep the same time.
Similarly, if we have a two day event that starts on 21/12/2016 09:00AM and ends on 22/12/2016 12:00PM (midday) and we drag the right end of the bar to extend the event by one day (keeping the mouse within the boundaries of 23/12/2016), we would expect that modifiedAppointment.End should hold 23/12/2016 12:00PM but it doesn't. It holds 24/12/2016 12:00:00AM.
In both cases, the time has been defaulted to midnight and in the second scenario, the date has moved two days, not the one day we dragged.
On the opposite end, if we drag the start of an event at 22/12/2016 09:00AM into 21/12/2016 we would expect modifiedAppointmentStart to be 21/12/2016 09:00AM but it is actually 21/12/2016 12:00AM - the time has got dropped. Even if you only drag halfway across 21/12/2016, the time still resets to 00:00:00 and takes no notice of the position of the mouse being only halfway across a cell.
Since you don't get the mouse granularity of time on the month view, you can't drop to a specific time within day, so it is not actually possible to drop at the right time. In this scenario, the time of the event should be retained. Time should only be adjusted in the day view where you do get the granularity of time.
Last time I looked, a day ran from 00:00:00 (12:00:00AM) to 23:59:59, not what RadScheduler is doing where the second after 23:59:59 is being treated as the same day!
This appears to be a serious bug which makes this feature unusable - it displays correctly, but the underlying data being reported is wrong..
Please advise.