FNCGrid sometimes get limited to the visible rows, according to it's height when data is loaded.
Yesterday I could load and export thousands of lines with no problems. Today, I don't know excatly what little tweak has been adjusted, that SaveToCSV, or SaveToCSVStream will only export the first nth rows that can be visible according to the grid's height. Strated with 18, now I've increased the form's height, and now I can export 31. But the grid is loaded. has 600+ lines. I can see the values by code, accessing Cells[x,y].
It doesn't export, it doesn't scroll down.
It happened to me before, but a slightly different. If grid had 7- lines when data was loaded, then it wouldn't scroll down and show all the data. So I just made sure it would always have at least enough height for 8 or 9 rows.
Now the same grid that was all well yesterday started "cutting" export and scrolldown.
Please, any ideas?
Thanks.
Really awfull! I found it !
It made me lose too many hours in the past.
In August when I created that topic: TMSFNCGridDatabaseAdapter w/ Web Core - After calling LoadAllDataAndDisconnect, data not being loaded when grid height is too short
That's because of setting the dataset's BlockReadSize property. After all yesterday issues with encoding were solved, today I added BlockReadSize to make things faster (a LOT faster).
That's what broke those functions !
@Pieter_Scheldeman , can you confirm that was the only problem all the time?
Hi,
Yes, that could very well be the issue. Note that BlockReadSize only buffers a set of records. When calling LoadAllDataAndDisconnect, the grid expects to read data from all records. So limiting this will in fact immediately result in missing data.
The # of records is not limited. When you use BlockReadSize, often to speed up forward-only scrolling on big datasets, the dataset behaves as a unidirectional cursor dataset and also as if you had called DisableControls. You cannot freely move back and forward as I it's done within the grid's data-binding mechanism. I didn't notice it before, till now that having set BlockReadSize was the only code change before this issue reborn yesterday.