jcompagner wrote:I can't give you any info to fix this in this release. We still need to figure out why it happens our selfs.
For now i guess don't use scrollable tableviews but use the normal paging one then it works fine and fast.
https://support.servoy.com/browse/SVY-2906 was fixed in 6.1.1 and worked really well. At least with webkit browsers and the following settings in place:
- Code: Select all
application.putClientProperty(APP_UI_PROPERTY.TABLEVIEW_WC_DEFAULT_SCROLLABLE, true);
application.putClientProperty(APP_UI_PROPERTY.TABLEVIEW_WC_SCROLLABLE_KEEP_LOADED_ROWS, true);
Servoy 6.2.2 fixed this issue:
https://support.servoy.com/browse/SVY-2588. Pretty sure it is responsible for breaking SVY-2906 though.
The problem is that grids with a scrollbar randomly reset (redraw completely) which pops the grid view back to the initial set of records. This is exactly what the 2588 fix does to grids when the window is resized to get the grids to resize.
I say "randomly" reset as we can't pinpoint the trigger of the grid reset. But what we've noticed is that it occurs almost all the time in the first few initial scrolls of a grid and sometimes when the user is doing nothing but other users are interacting with the same grid in another swc session (not sure if there is a correlation here).
It is worth noting that this doesn't happen to grids that don't have a vertical scrollbar (because larger viewport than total rows). Also, our grids almost exclusively have all four anchors set so haven't tested with various anchoring configurations.
We should have caught this in our initial testing of 6.1.2 but for some stupid reason we didn't have loaded up a grid with our usual 10,000 rows. Just assumed from our 6.1.1 testing that it was all cool. My apologies.
Be glad to test any private builds of future releases before they are released. Getting scrolling grids to work is also an absolutely critical issue for us.