strange numbers (showing 6987 to 7001 of 5840 entries) with scroller plugin

bwlang

I can reproduce this when i turn on the scroller (by adding the S to sDom)
by scrolling down a bit with the mouse wheel, followed by a drag of the slider to about 2/3 of the way down.

Sometimes i have to scrub around a bit for the numbers to get wacky.

this is with 1.8 + the scroller plugin from yesterday
firefox 5 or latest chrome.

here are my options
var gTableOptions = {
"sDom":"lpfrtpilS",
"bStateSave": false,
"bSortClasses": false,
"oLanguage": {
"sSearch": "Search this table:"
},
"sScrollY": 300,
//"bScrollInfinite": true,
"bScrollCollapse": true,
"bPaginate": false,
"bProcessing": true,
"aaSorting": [],
"bDeferRender": true
};

For now i'm just sticking to the bScorllInfinite and no scroller

allan

There are two possibilities which come to mind:

1. The rows have variable height - for Scroller to work, they all need to be the same.
2. The row height which was calculated is "out-of-date" - i.e. the styling applied to the table has changed the row heights from what was initially calculated.

I plan to an an API function to allow recalculation of the row hight for the second. To be sure of which one it is, I'd need to see the your example.

Allan

bwlang

I suspect a changing row height... i expected rendering problems from this, but not strange numbers...
I don't think i can guarantee row height, so this won't be a great option for me i guess.

allan

Nope - I'm afraid not. There is an introduction to Scroller and how it works here: http://datatables.net/blog/Introducing_Scroller_-_Virtual_Scrolling_for_DataTables . One option is to use CSS to force all rows to be the same height (either the max height or the content on a single line) - but this is a fundamental requirement for Scroller since it doesn't know the height of each individual row and therefore needs to make some assumptions.

Allan