C=Math.round((s+p)/h)+1; in populateVisible function with C2=Math.ceil((s+p)/h)+1;

tony said:

Hello,

Thank you for the recommendations.

This feature should be carfully checked and corrected.

Best Regards

Tony

Just wondering what the progress on this bug is?

I found it still has not been addressed in the 3.8 demo so I have manually edited in 3.7.2 as per initial suggested fix and its all working ok (as far as I can tell).

For those wanting to hack the minified version.. just search for "===undefined||" and you will find a line with the same logic but (naturally) different veriable names eg:

c.lastpage===undefined||parseInt((s+p+h-1)/h,10)<=c.lastpage

Thanks

I've got thousands of rows in my table and when they are all already preloaded (no additional auto load happens on scroll), I notice a slight delay when I try to move a scrollbar with the mouse. Scrollbar doesn't move for at least 2-3 secs, it looks like it is undergoing some intensive calculation. After it starts moving, scroll becomes smooth again. But if I release it and try to drag the scrollbar again, interface hangs for some time again.

When new rows are preloaded on scroll such delay maybe understandable, but I do not see why it can be happening when all rows are already loaded. This makes the interface to look a bit sluggish.

Anyone any idea of what can be the reason for this and how to eliminate it maybe?

I tried some changes, and the case (which last page won't be retrieved) happened when I changed the line below.

You can trigger the symptom with this change. I don't know if it helps, but just FYI.

Thanks

I wasn't thinking of fixing this in such way at all. Initially I was planning to do a reset of some kind after a change in grid height, but didn't know what to reset and where? I was hoping that it is somehow possible to accomodate scroll size to a new height maybe…

What you guys think?

I had the same problem with the newest version (3.7.1), and Klaus's solution worked fine.

Thanks.

Thank you for the recommendations.

This feature should be carfully checked and corrected.

Best Regards

Tony

maybe you could improve this the following way ...

1) better validation/consistency checks: same rows (with same ID) should never be inserted into the grid - because this doesn't work anyway (selection of rows with same IDs is corrupt, ...)

2) better validation of paging values (esp. when in scroll-mode): sometimes it happens when scrolling too fast in a huge data set that the AJAX-loading-requests get in trouble (some not finished while invoking other ... or so) and the pages get mixed up or even the grid will stay sometime empty (when the paging is really corrupt and the grid tries to load a non-existing page)
... so loading negative pages won't work anytime and loading pages above the max also will not work.
... maybe you could also check when scrolled to the top to load page=1 and when scrolled to the bottom to load page="total" ... that may help the user to recover loading problems by simple scrolling to one end of the scrollbar.

Kind regards,
Klaus.

Thanks Klaus. This will fix your issue, but will go to the older one where the last page can not be requested.

Humm, will investigate more deeper the problem.

Best Regards

Tony

After updating to the latest jqGrid release 3.6.5 I detected the following problem:

For all my tables using "true scrolling" (scroll:1) the table content is duplicated with each setGridHeight.
The Record info says: "View -9 – 2 of 2″.
Also when I scroll inside such a grid the records are duplicated.

When press the RESET-button, the records are loaded correctly (without any duplicates).

I'm using deepempty:true (but also tried with deepempty:false – without any change).

The calling order is: