We have a grid that requires horizontal scrolling due to the number of columns present. We also have Static Headers = true so the headers remain while vertical scrolling. When in Batch edit, with AllowKeyboardNavigation = true, the headers do not scroll horizontally with the data.
The width of the grid is set at 100% and each column is sized using headerstyle-width. itemstyle-width is not used anywhere.
When we remove the static headers, the headers scroll horizontally correctly, but of course, the headers scroll out of view when you vertically scroll.
Is there some way to get the horizontal scrolling to work properly with keyboard navigation and keep Static Headers?
6 Answers, 1 is accepted
Some more information:
This is happening when using the tab key to navigate from one cell to the next.
On Chrome: The headings do not horizontally scroll with the data and the frozen columns scroll off the grid (only come back when you use the horizontal scroll bar to go to the very end of the data).
IE and Firefox: The headings scroll with the data, but the frozen columns still scroll off the grid (Same as above).
Have not yet tried Safari or Edge.
Any ideas what may be causing this?
To make scrolling of the content smooth while using static headers, you can set the ClientSettings-Selecting-CellSelectionMode to SingleCell and disable FrozenColumns, thus you can easily navigate left and right within the table. Please note, the combination of Frozen column and inline editing (InPlace or BatchEditing) mode is not supported. (for more, you can check out the Unsupported Scenarios and Frozen Columns - Limitation)
Please test the sample page from the attachment to see the above scenario in action.
I hope this will prove helpful.
Thanks Attila, that was the problem. The scrolling is working as expected now.
The next task is to get the up and down arrow keys to not change the selection in combo boxes and date pickers.
Please check out the following article, which might be the answer for that question Cancel Enter and Arrow Key Press.
Could you please try to use the args.get_domEvent().preventDefault(); method instead and see if that will cancel the event?
If the issue still persist, please try to modify the sample I've sent earlier that will resemble the scenario at your side and send it back to us for further investigation.