Would it be possible to add a method to JS API to scroll Grid viewer content to a specific (x,y) point? We are developing a number of features that require this functionality.
Sure, we’ll expose it. Just to clarify, you need the ability to scroll to the particular table cell (identified by the column x and row y) and not to the screen coordinates?
We need to be able to scroll to any part of any cell (not just to cell bounds). The domain for x -coordinate is [0, Wcells - Wvp], where Wcells is the sum of all cells’ widths and Wvp is the width of the viewport of the scroll pane. Same applies for y-coordinate domain [0, Hcells - Hvp], where Hcells is the sum of all cells’ heights and Hvp is the height of the viewport…I hope this clarifies the requirement.
We’ve just exposed two methods for grid scrolling, scrollToCell(column, row) and scrollToPixels(x, y).
Note that currently, it is not possible to vertically scroll with pixel granularity (row separator positions do not change as you scroll), so for the scrollToPixels method we are truncating y to the top of the first visible row. There is no such limitation for the horizontal scrolling.
Here are the examples:
Thank you for adding this functionality! It would be also great to have a couple of getter methods to query current horizontal and vertical viewport scrolls. Something like horzPixelScroll() and vertPixelScroll(). Could you please add those or similar to JS API?
We added getters for scrolls and getters/setters for their values, this improvement will work in the next dev-build(~15 minutes). You can check it in this commit or in this and this snippets.
Here is the corresponding snippet: https://dev.datagrok.ai/js/samples/grid/scroll-bars
Keep in mind that the values in the horizontal scroll bar reflect pixels, but vertical scroll bar values are row numbers. We might harmonize it in the future (together with introducing pixel-based vertical positioning)
There is an issue with the scrollToPixels() method. In the following snippet after clicking on the top left cell (on the column header) the corresponding column (with index 0) is supposed to be completely hidden by the scroll, but apparently the scroll request was completely ignored. In fact, scroll requests are ignored after clicking on any cell on the column header.
let nRowCount = 1000;
let nColCount = 100;
let grid = grok.shell.addTableView(grok.data.demo.randomWalk(nRowCount, nColCount)).grid;
rxjs.fromEvent( grid.overlay, 'click').subscribe((e) => {
let nButton = e.button;
if (nButton === 0)
{
let cell = grid.hitTest(e.offsetX, e.offsetY);
if (cell.isColHeader) {
cell.gridColumn.width = 250;
grid.scrollToPixels(250, 0);
}
}
});
Apologies for the late reply, there were a couple of issues that needed to be addressed. For performance reasons, when the column widths are changed programmatically, the recalculation of the final grid layout gets postponed until the next rendering, and this messed up with this example. To address this, we have exposed a new function in our JS API - grid.runPostponedComputations()
. We are also calling this function when scrollToPixels
method is executed, so the example above now works as expected, but still for some other cases you would need to call grid.runPostponedComputations()
explicitly when you change column widths and access other layout-related functionality before the next rendering event.
The fixed version will be available on dev in 30 minutes.
Thank you for all the changes and fixes you have made! Will it be also possible to enable vertical scrolling with pixel granularity?
We developed a continuous zoom feature (with mouse wheel) which now works awesome horizontally. If this zoom could work same way in both directions, it would dramatically improve the user experience.
Great to hear that and looking forward to see it in action! Yes, we’ll implement that once we deal with the other pressing issues. I totally agree that continuous zooming is cool, we’ll get there