I need to show the scheduler right to left group by date with scroll in week view. The problem is with the horzinotal scroll that double click on a cell recognize the cell resource wrong.
In my opinion, the error isn't in the double-click operation, but in how the scheduler translates the X-coordinate after horizontal scrolling in right-to-left mode. Without normalizing the offset according to the RTL layout, incorrect cell recognition is almost certain to occur. Polytrack
Neli
Telerik team
commented on 07 Jan 2026, 11:07 AM
Hello,
There is no built-in setting to automatically normalize X-coordinates for the RTL Scheduler with horizontal scroll. You can try customizing the event handling logic. Specifically, you can adjust the calculation of the X-coordinate in your cell click or double-click handlers. Here is a basic example of how you might approach this:
$("#scheduler").on("dblclick", ".k-scheduler-table td", function(e) {
var scheduler = $("#scheduler").getKendoScheduler();
var scrollLeft = scheduler.element.find(".k-scheduler-content").scrollLeft();
var clientX = e.clientX;
// For RTL, adjust the X coordinate based on scroll position and container widthvar containerWidth = scheduler.element.find(".k-scheduler-content").width();
var normalizedX = containerWidth - (clientX + scrollLeft);
// Use normalizedX to determine the correct cell/resource// ... your logic here ...
});
You may need to further adjust the logic depending on your exact Scheduler configuration and layout.
var slot = scheduler.slotByPosition(normalizedX,e.clientY);
but the slot.groupIndex is not the right one?
Neli
Telerik team
commented on 13 Jan 2026, 07:09 AM
Hi Dov,
When using scheduler.slotByPosition(normalizedX, e.clientY) in RTL mode with horizontal scrolling, an unexpected , usually means that the X coordinate does not fully align with the RTL layout and the current scroll offset.
Under the default configuration, the Scheduler calculates this correctly by determining the X position relative to its content area while accounting for both scrolling and RTL direction.
We understand that custom styling is sometimes necessary to meet specific layout requirements. However, in this case, modifying the Scheduler’s width and layout through custom styles affects its internal coordinate calculations, which can lead to this behavior. To ensure consistent and predictable results, we recommend staying as close as possible to the built-in layout and scrolling behavior, as scenarios involving custom sizing and positioning fall outside the supported use cases.
Hello,
There is no built-in setting to automatically normalize X-coordinates for the RTL Scheduler with horizontal scroll. You can try customizing the event handling logic. Specifically, you can adjust the calculation of the X-coordinate in your cell click or double-click handlers. Here is a basic example of how you might approach this:
$("#scheduler").on("dblclick", ".k-scheduler-table td", function(e) { var scheduler = $("#scheduler").getKendoScheduler(); var scrollLeft = scheduler.element.find(".k-scheduler-content").scrollLeft(); var clientX = e.clientX; // For RTL, adjust the X coordinate based on scroll position and container width var containerWidth = scheduler.element.find(".k-scheduler-content").width(); var normalizedX = containerWidth - (clientX + scrollLeft); // Use normalizedX to determine the correct cell/resource // ... your logic here ... });You may need to further adjust the logic depending on your exact Scheduler configuration and layout.
Regards,
Neli
Progress Telerik
Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.
I need to use slotByPosition like so:
var slot = scheduler.slotByPosition(normalizedX,e.clientY);
but the slot.groupIndex is not the right one?
Hi Dov,
When using scheduler.slotByPosition(normalizedX, e.clientY) in RTL mode with horizontal scrolling, an unexpected , usually means that the X coordinate does not fully align with the RTL layout and the current scroll offset.
Under the default configuration, the Scheduler calculates this correctly by determining the X position relative to its content area while accounting for both scrolling and RTL direction.
We understand that custom styling is sometimes necessary to meet specific layout requirements. However, in this case, modifying the Scheduler’s width and layout through custom styles affects its internal coordinate calculations, which can lead to this behavior. To ensure consistent and predictable results, we recommend staying as close as possible to the built-in layout and scrolling behavior, as scenarios involving custom sizing and positioning fall outside the supported use cases.
Regards,
Neli