I have a grid into which I am injecting editors dynamically. When I inject Kendo UI controls the scrollbar on the grid gets reset to zero. The code that is doing this is VirtualScrollable.refresh():
refresh: function () { var that = this, dataSource = that.dataSource, rangeStart = that._rangeStart; kendo.ui.progress(that.wrapper.parent(), false); clearTimeout(that._timeout); that.repaintScrollbar(); if (that.drag) { that.drag.cancel(); } if (rangeStart && !that._fetching) { that._rangeStart = dataSource.skip(); if (dataSource.page() === 1) { that.verticalScrollbar[0].scrollTop = 0; } } that._fetching = false;}
The problem is that this method is assuming that if the datasource page is 1 then it should reset the scrolling, but in my case neither my grid nor my data source are using paging at all, so when the user edits in the grid while they are scrolled down the page, this code returns the scrollbar to the top, while the logical edit is left down the page. This is even more confusing as I am using fixed left columns (which means there is really two grids on the page) and the fixed grid doesn't scroll in response to this change, so the user has a very broken experience.
I also don't understand why a method called "refresh" is calling dataSource.skip(). I also don't understand what part of creating an edit field (instantiating an edit template) causes this refresh to be called.
My Grid is configured like this:
$("#grid").kendoGrid( dataSource: ds, columns: dynColumns, scrollable: { virtual: true }, pageable: false, sortable: true, editable: true, batch: true, navigatable: true, resizable: true, /* Other stuff */}
It seems to me that this code should be checking to see if the data source is being paged before erroneously adjusting the UI. Unfortunately, other than editing the Kendo source directly, I haven't yet found a workaround for this problem.
Is this just a bug, or am I configuring something incorrectly?
Scott
7 Answers, 1 is accepted
Rank 2
OK, I figured out why it is calling VirtualScrollable.refresh(). Somewhere between closing one edit template and opening the next edit template (in response to hitting the TAB key) the grid is actually destroying and rebuilding the scroll bar. When it does this it calls VirtualScrollable.refresh() which resets the scrollbar to the top. I don't know exactly where this is happening yet, but the problem isn't the refresh() function, it's just a symptom of the real problem that the grid isn't maintaining the scroll bar while editing.
Something that I found while researching this is that occasionally the grid fails to build the new scrollbar, thus when going between edit fields I sometimes lose the scroll bar entirely, but generally when I tab to the next field it returns. So far, at least, I've never seen it lose the scrollbar two fields in a row, and I haven't been able to identify a pattern as to when it will fail to build the new scrollbar.
Thanks again to anyone who can offer suggestions,
Scott
Currently using editing with virtual scrolling is a limitation as you can verify from here. However in the upcoming release you should be able use virtualization with editing without any problems. So stay tuned and check out the release notes for the next release.
Regards,
Angel Petrov
Progress Telerik
Rank 2
Thanks Angel for the validation, that's basically what I found. There were a number of bugs I had to work around related to correct scrolling of both the fixed columns and the non-fixed columns (which is implemented as side-by-side Kendo Grids and a virtual scrollbar). I also had to fix several bugs around properly maintaining the styles across the two grids (some rows in one or the other would either not get set or would not get reset). Tab support in this scenario was completely broken, I had to implement a completely custom method for managing tabbing around the table (onKeyDown).
In the end my problem didn't seem to have anything to do with rebinding the data source, but happened when moving between edit fields in the grid. The grid would disable the virtual scrollbar during the transition. The strangest thing is that sometimes it would completely delete the scrollbar object and recreate it (in $("#grid").data("kendoGrid").wrapper.find('.k-grid-content').data('kendoVirtualScrollable').verticalScrollbar), but regardless of the method it always reset the scrollbar to zero (without moving either of the actual grids).
The way I chose to solve this was to monitor this transition and when the scrollbar actually exists and is out of alignment, I reset it to match the non-fixed column grid's top row, like this:
function fixScrollBar ()
{
// Get the first visible cell's scroll offset
// We use the unlocked (editable) cells here, but the locked cells should be synchronized.
var firstCellOffset = $("div.k-grid-content div.k-virtual-scrollable-wrap").scrollTop();
// Set the scrollbar propertly
var scrollBar = $("#grid").data("kendoGrid")
.wrapper
.find('.k-grid-content')
.data('kendoVirtualScrollable')
.verticalScrollbar;
// If at any point the scroll bar goes away while we are trying to do this, // just skip it, we'll catch it next time.
if (scrollBar.length > 0)
{
scrollBar.scrollTop(firstCellOffset);
}
}
It's a hack, but it seems to be working. My only other choice was to take over managing the scrolling entirely myself, which, if this fix doesn't prove solid, is still an option.
If you are using an OData service with remote binding or are extracting the data locally you can enable data editing and virtualization with the latest 2017 R3 release. A demo that demonstrates this approach can be found here.
If however this is not the case you can stick to the workaround that you have currently implemented.
Regards,
Angel Petrov
Progress Telerik
Rank 2
I appreciate the reply, but we aren't dealing with anywhere near that amount of data. The most we might possibly have is a few hundred rows. The problem seems to happen when an single cell editing template is instantiated. Some process is hiding the scrollbar just after the edit field is committed and before the next edit field. Generally, while the edit field is being edited the scrollbar is there, but between the two fields it resets the scrollbar. My fix reset *that* scrollbar reset.
Unfortunately, my fix only partially worked as it turns out if the user clicks out of the edit field (clicks in open space while an edit template is active) the scrollbar is never re-enabled. So, we end up in a state where the scrollbar isn't visible and resetting the scrollTop doesn't cause it to reappear. In fact, I have not found anything yet that reliably causes the scrollbar to appear in this situation.
At this point I think I'm going to simply disable the scrollbar entirely and substitute one that I will manage myself. Because of the bugs I think it will actually be less code doing it myself than all the special cases that's in there now trying to get around the various bugs. Ack!
If you don't have a large amount of records you do not need to enable virtualization. You can just enable scrolling and paging alongside with data editing.
If you have problems using the above I suggest posting the code of the view so we could examine the setup and provide you with straight to the point suggestions.
Regards,
Angel Petrov
Progress Telerik
Rank 2
Angel,
If you don't have a large amount of records you do not need to enable virtualization.
You can just enable scrolling and paging alongside with data editing.
This turned out to be the right answer, but it was masked by code that was fixing bugs in the grid when the virtual scrollbar was enabled. Once I turned off the virtual scrollbar (which I thought I needed to do all of the fixed columns and rows) and removed a bunch of my code trying to resolve problems with the virtual scrollbars, I still had to do some work to keep the grid properly filling its part of the page, keeping the fixed and variable column tables in sync, and scrolling full rows onto the page, but the scroll jumping problems went away completely.
Thanks!