Last Updated: 25 Feb 2014 11:07 by Sam
Created on: 26 Jul 2013 06:44
Category: Scheduler
Type: Bug Report
RadScheduler Client-Side Script OnClientAppointmentMoving TargetSlot Start Time Incorrect
When moving from 2.611.45 to the latest 2.717.45 ASP.NET AJAX binaries, we are experiencing a problem with the client-side drag ('move') of appointments.

Repro steps:
* Unpack the attached MVC project (bare-bones...does web-service binding on an XML document). Run the project (just go to the /Home/Index action). You should see the RadScheduler there.
* Create an appointment of AT LEAST 90 MINUTES duration. This should succeed.
* Drag the appointment up/down. I have included a piece of sample JavaScript which prints out the eventArgs.get_targetSlot().get_startTime() value. 

Expected results:
* The logged value coincides with the visual position of the start of the appointment while it is being dragged.

Actual results:
* The logged value is offset by a constant amount compared to what is being shown on the Scheduler during the drag. For example, the appointment will appear to be shown at 12:00 but the value retrieved in script will be 12:30.

This only seems to be reproducible for appointments of 90 minutes or longer. It does not occur with your 2.611.45 binaries.

I noticed that you guys changed your implementation of client-side methods like _startDrag, _raiseMoveEnd, _finishDrag etc in this latest might have something to do with that, but I didn't have time to go debugging your script.

(Note: The attached zip is only a zip of the cleaned project file. The only non-standard MVC4 assemblies are your Telerik assemblies, so you'll just have to fix up the path to those so that the project builds.)
(Total attached files size should be smaller than 20mb. Allowed extensions: .zip, .rar, .jpg, .png, .gif)
1 comment
Posted on: 28 Nov 2013 18:07
This is still a problem in the latest binaries (2013.3.1114.45). This is frustrating for our business: we purchased a subscription yet cannot upgrade to the latest version of the controls due to this issue. We would appreciate it if you could prioritise this.