View Full Version : [CLOSED] 2.0 M3 (editable) buffered grid bugs

12 Jun 2009, 12:28 AM
2.0 m3, osx 10.5.7, firefox 3.0.9 and safari 4.0

dear dev team!

congratulations for the 2.0 version!
it's a great step forward!

one thing i was longing for was the buffered grid and editable buffered grid.
i am just using the explorer sample of m3.
(http://extjs.com/examples-dev/explorer.html#editablebufferedgrid)both work well under firefox and safari if you do not zoom.
zooming in destroys the behavior and after scrolling there is no content displayed in the grids area. maybe you take a fixed size height which is not correct....

by the way: will it be possible to have different rendering heights for different rows like it is possible in non buffered grids? would be great if the buffered view implementation will store the rendered height of each row....

thanks for your great work!

regards, kht

12 Jun 2009, 2:53 AM
BufferedView is for displaying a large amount of simply data. RowExpander etc are not going to work, so also not different row heights or zooming. I am going to close this topic.

12 Jun 2009, 3:59 AM
hi sven,

please dont close this topic.
even if no row expander can be used nor different row heights.
the displaying of large amounts of simply data does not work!

please open the explorer, and simply press command+'+' keys to enlarge the page. and then look what happens to the buffered grid!

regards, kht

12 Jun 2009, 4:17 AM
BufferedView was not designed to be used in such a way. It is really not supporting all normal grid view features.

WebKit for example increases the height while zooming. FF just zooms without doing that. All the calculations are based on the rowheight. So while zooming the rowheight changes, but as you configured the rowheight to a specific size, it fails.

12 Jun 2009, 11:08 AM
hi sven,

yes, i can imagine that.

what about measuring rendered rows and store the size of each row? or if you want to make it fixed height each row, that on rendering if the height differs, the calculation is adjusted.
this would help in case of zooming and in case the buffered grid is resized if thr browser window is resized....

regards, kht

12 Jun 2009, 11:10 AM
The calculations for that would make the bufferedview even slower than the normal view.

14 Jun 2009, 6:20 AM
hi sven,

i did that already in java, using embedded mozilla for displaying those large lists (generating nodes on the fly). it is all very fast and i use it in some cases even for 500.000+ rows. even during dragging most time the rows where immediatly rendered - only in some cases an area was white and with short delay rendered.
after rendering i measured each row and stored the hight in an int array... as size of the grid could change i always had to measure the height again after each rendering. thus it even could have been that the current displayed area was too short after rendering the rows, so i had to render additional rows to fill the gap. of course i had to adjust the scrollbar values after rendering the visible part of the list to show the difference between the assumed height (previously rendered heights or default heights) and the current rendered height.

if you want i can send you some java code i did.

anyhow, for now i even can live with fixed heights of the rows as long as zooming bug is fixed....

regards, kht