Could you please check the last from GitHub. I have make some chenges to this.

Regards

Tony

I have one request to you.

Could you please prepare live example and send me a link. You can send me PM or e-mail me to tony at trirand dot com.

Thanks

Tony

Thanks. Im going to be away for the w/e so wont be able to look at it until Monday.

One more thought... Math.round may be the answer after all.

The current formula is supposed to take a pixel value, and return the page that contains that pixel. For that, Math.round would be wrong (if you were in the lower half of the page, it would give the /next/ page).

But in this case, if all the calculations are correct, the pixel should always be the /first/ pixel on the page. But Im guessing (from Kaleb's investigation) that something isnt quite adding up, and we're getting an off by 1 (or perhaps off by border, or margin, or padding width, or some such) error. So Math.round ought to give the correct result.

Somehow doesnt feel right, because its just hiding the fact that the calculation isnt quite correct... but I think it /should/ work, as long as the error is less than half a page :-\\

For the cells with images case... if the rows aren't all exactly the same height (?), the scrolling rows feature just isnt going to work as it stands (it depends on being able to translate back and forth between pixel offsets and row numbers /without/ having looked at all the preceding rows). I think it may be possible to fix that, but would require changing the scrolling logic somewhat...

Mark

Here is another similar IMHO:

http://www.trirand.com/blog/?p.....ed/#p11646

I will take a look at the problem these days.

Tony

I've tried single clicking the scroll arrow all the way down to row 100, and Ive tried paging down until Im close, and /then/ single clicking... what exactly do you mean by scrolling "slowly" down to row 100?

Mark

It does look like IE is not reporting the positions correctly. If I add one to the function below it works in IE fine.

                    if (ttop <= 0 && tbot < dh && parseInt((tbot + scrollTop + div - 1) / div) < p.lastpage) {

                        npage = parseInt((dh - tbot + div - 1) / div);

                        if (tbot >= 0 || npage < 2 || p.scroll === true) {

                            page = parseInt((tbot + scrollTop + 1) / div) + 1;

                            ttop = -1;

                        } else {

                            ttop = 1;

                        }

                    }

markw65 said:

I'll take a look at this… but unless IE is reporting the positions incorrectly, Math.round is the wrong function. It /has/ to truncate to get the correct result.

Mark

Cool thanks Mark!

Mark

I replaced the parseInt with the Math.Round function and it rounds up to the next whole number instead of going down a whole number like the parseInt function does.(ex. if number is .99 the parseInt function will make it 0)

Starting at Line 272 in the "grid.base.js" file.

if (ttop <= 0 && tbot < dh && parseInt((tbot + scrollTop + div - 1) / div) < p.lastpage) {
npage = parseInt((dh - tbot + div - 1) / div);
if (tbot >= 0 || npage < 2 || p.scroll === true) {
page = Math.round((tbot + scrollTop) / div) + 1;
ttop = -1;
} else {
ttop = 1;
}
}

Browse here http://www.trirand.com/jqgrid/.....ml in IE7 or IE8.

Open the true scrolling demo.

Scroll down the list very slowly until you get close to the hundredth row. Right when you go path the Hundredth row it will throw an error about an invalid argument which is a negative height. In my case it was trying to set a height to -575px and IE was throwing an error. I also noticed that when this happened the grid did not load the next page but it reloaded the first page. Maybe this is where the issue stems from?

If you scroll down the list real fast it works fine it is only when you go past that last row slowly.

Once again thanks for the great product!

Kaleb