I am scratching my head on this one but I am starting to think it may be a bug in ag-grid.
I have a grid that is (inconsistently) only rendering 3 rows of data when I am expecting 5. There is a blank space for the 2 missing rows.
The pager says 5 rows, and the grid seems to know there are 5 rows (when I step through the javascript debugger). In fact, if I sort on the grid, or resize the window such that the grid provides scrollbars, the other 2 rows suddenly appear.
Has anyone seen anything like this?
----More detail but may not be relevant:
On this particular page, I have 2 grids. There is a main grid that has links in it, and when you click into a link, it hides the main grid and shows you the other grid. I was concerned that that was coming into play somehow, but I actually have seen this on another page I'm working on that has just 1 grid.
Based on various explanations I have seen online, I tried this and it appears to be working:
setTimeout(function ()
{
$scope.gridOptions.api.refreshView();
}, 0);
I call this after
params.successCallback(pResponse.data);
which invokes the grid's callback
Based on your observations that sorting or resizing the window makes the data appear, I get the feeling that the code needs to force the screen refresh somehow.
this.gridOptions.api.refreshView();
I had a similar issue and discovered that my gridOptions.rowHeight value did not match the actual height of my rows (I had a checkbox element in each row that was pushing the height taller).
As it turns out, the AgGrid row renderer uses absolute pixel location to calculate which rows should be visible. So if your actual row heights result in the rows not being in the exact position they are expected to be in, the renderer will skip them.
Ironically, the positioning code uses actual position, so the rows that do get rendered are positioned as if the skipped rows are still there, resulting in the blank space described by the OP.
Related
ag-grid-enterprise v20.2.0.
Chrome v73.
I have several columns and a large data set with a full-screen grid. I don't have any custom renders and I'm using batchUpdateRowData() to add to the grid.
When my app loads, I load a history of up-to 20000 records. Each time the grid draws it takes ~150ms (as per the console).
Are there any suggestions for improving the draw performance...or am I expecting too much? Due to the amount of data being loaded at start, each draw is a full re-draw of grid.
Unfortunately I cannot avoid loading these records.
Extra info:
The reason why there is a redraw is because my grid is sorted by timestamp descending and the history is loaded oldest to newest. It's loaded from a persistent topic, so has to be loaded in that order annoyingly.
1) Given that you are loading 20000 rows, your biggest issue would be Ag-Grid trying to load and display all 20000 of them when your component starts up. You should use infinite scrolling, which displays only a fixed amount of rows on your viewport/Ag-grid table, and dynamically removing the 'hidden' ones loading the rest while you scroll along the grid. In short, you have to set the rowModelType property to infinite.
2) This point is regarding your row buffers, and it has a similar concept as the point above.
3) Another alternative to doing infinite scrolling is to use server-side pagination, whereby you only fetch x-number of rows for that given page, and fetch more as you scroll down/to the next page.
4) If possible, try not to disable suppressColumnVirtualization, as the original settings for can have a slight improvement on performance since the non-visible columns are rendered until it is scrolled to.
I have an ag-grid display with about 1000 rows and 3 columns ... initially the display looks fine ... but as I scroll, somewhere around the 150th column.. my grid display gets messed up .. I stop seeing the border, scroll bar, header of the grid and left and right columns disappear ... below is an image of what I see. if I scroll further down, I will stop seeing the left and right columns and the header completely..
Any help on this would be greatly appreciated.. I don't even know where to look.
(Note: please ignore the black lines in the left column. I had to cover the text before I can post the image here.)
thank you
Vij
I had the same problem, when i used Internet Explorer.
I'm not so sure, that in your case it is the same, but my problem was solved with the lagging.
When you initialize your ag-gird add this to it:
suppressScrollLag: true
I hope this solves your problem.
One other option, even though it's not the most elegant one, is to increase the number of rows that get rendered outside the viewable content:
gridOptions.rowBuffer = 100;
The default is set to 20 rows.
So I have a grid in Zkoss with a certain amount of columns. One the first row I place two labels which fill the first two columns (as expected).
I've written their style so that they don't have change color when you hover the mouse over them however one of the columns label is much bigger than the other and when I hover the mouse over the smaller label the area around which isn't filled by the text goes to white.
ZKFiddle example
I'm going insane around this as I'm simply unable of making that area have the same background as the label.
Like I already said in your duplicated question.
CSS is responsible and you just need to search with developer tools.
This update to your fiddle tooks me 2 min.
The changed thing :
.z-row:hover > .z-row-inner, .z-row:hover > .z-cell {background:red; !important}
i have a grid where i need to show the sum of a column at the end of the grid. I use the function
myListGrid.setShowGridSummary(true);
if the grid contains 60 records it will do the summary without problems, if it goes >61 the summary will show no data at all. I believe this problem is caused by the grid paging (not loading all the data at once). Is there a possible workaround for this or maybe a function to load all the data that i'm missing?
myListGrid.setShowAllRecords(true)
Drawing all rows causes longer initial rendering time, but allows smoother vertical scrolling. With a very large number of rows, showAllRows will become too slow.
I have a gtk treeview (inside a GtkScrolledWindow) with two columns.
If I set both columns to the default sizing policy, I have a horizontal scrollbar for the treeview but the columns can't be sized down by the user, which is impractical.
If I set both columns to setSizing Fixed, fixed width 120, I get a nice display and the columns can be resized, but there is no horizontal scrollbar in the treeview (since the columns size down to fit in the width of the treeview I guess).
If I set the first column to setSizing fixed, fixed width 120, the second one to automatic, only the second column is displayed (???).
I would like that by default the first column takes let's say at most 60% of the display, the second column can go all the way and I have a horizontal scrollbar. Certainly I want the user to be able to resize them up or down, not as with the default policy, that you can resize them down!
That's why I tried the first column fixed, the second automatic, it was promessing but I don't understand why the first column is not displayed at all in that configuration.
I add the cell renderers with packstart true, I tried false but it didn't change anything, also I tried setting the expand for the columns to true or false, which didn't have any effect.
Note I'm using the gtk2hs haskell bindings but I'm certain it would be the same in any other gtk binding. Just mentioning if people will ask for code samples.
I'm pretty sure this is a common problem... I'd say nautilus is fixing it the way I'd like to fix it, but I think digging in the nautilus source is going to be quite long...
EDIT well i've discovered the cell renderer's ellipsize setting also has an effect. Setting it to end for the first column and none for the second should be what i want but then the first column is very small and cannot be expanded through resize...
EDIT2 well for now i've moved to word wrapping for the cell renderer, that way i don't have to bother with a horizontal scrollbar... Still curious for the solution to that question though.