Hi. My name is Hong.
we have bought the dhtmlxgrid and tree last January(01,2010) and
it runs well. Althought it’s great function and design, we met some trouble in using
smart rendering.
-Detailed Explanation-
As your smart rendering example "product Name || Internal Code || Price ", we applied the smart rendering to the big dataset. When scrolling down the window,
“some data” are invisible. but It was not blank data. Also, scrolling up the window,
data are visible. I think, smart rendering has position problem.
What is the solution in this situation ? Help us as soon as possible.
Does your rows have standart height? If rows height has been changed you should tell the grid new row’s height with setAwaitedRowHeight(height) method docs.dhtmlx.com/doku.php?id=dhtm … drowheight
IE8 related with bigger datasets on a fast computer. Scrolling down 4 to 5 pages and scrolling back leaves “holes” in the renderd grid with no data in it. Data gets not updated when scrolling in to the blank are as we can see on the server side (no requests).
Tried to load bigger chunks of data from the server, but this moves the problem w/o solving it.
FireFox is fine, IE8 on a couple of machines does. As from the grid example whith the 50,000 records we gues that this might be a timeout problem. The sample is generating the data fromout php literally, we are actually picking it from a database.
no, the error does not occur in the online sample of dhtmlx. Where’s the difference?
I had a look at the example, and found out following:
as soon as the parameters posStart and count are submitted on the URL (i.e. smart rendering starts), you don’t provide a total_count in the returning XML.
Furthermore, you don’t have buffering enabled with smart rendering, leaving it up to the grid on how many recors are fetched in one bunch.
I have altered my code accordingly, but with no changes basically at IE. FF is slightly faster now, but IE has become dead slow on large jumps in the grid and we still have the “holes” in the grid.
Fiddling around with some traces from there leads to the following:
It seems (!! not quite sure of course) to be a row hight caculation problem on IE. I’ve populated one columns with the effective row # and got the following:
scrolling forward issues a reload of a bunch of records from the database starting at # 2060 and requesting 100 records.
The record with # 2060 allthough is not rendered at the top position but leaves a space, see attached screenshot.
Either grid is assuming that the other records ar already in or is starting at the wron position to render. Thie very request was the second request against the database: first (0 : 100), second (2060 : 100).
Taking screenshots from my app and the sample app and measuring actual pixel height of rows I found out:
The actual row size in our table is 22 due to a general stylesheet which adds borders to any table. So actually the row hight wasn’t 20 as from the standard but 22 px (sic).
Setting setAwaitedRowHeight(22) did the Job: IE8 works perfectly now as well.
Final Question: why hasn’t this error occured in FireFox?
And: this might be worth a mention in the documention probably - would have saved me a couple of hours.
Because in FF, borders are within the box and not outside.
Yep. If you are using IE in standard mode ( full doctype ) the height must be equal but in quirks mode things are different.
Also, you can try to use grid in multi-line mode, in such mode height of row is based on content and not fixed to any values, so grid will autodetect height of rows.
