However, if you pass a version property, the store will read it out and fire this event if the value changes between two (buffer) requests.
What you do with it is up to you - if you have pending selections (i.e. ranges of row-indexes (NOT! record indexes)) which should be selected, but for which no records have been loaded yet, you could remove those selections as you would not know if any data has been slipped right in between this range of selections, which could lead to data inconsistency if you're about to send a "delete" request to the server with the ranges of pending selections available.
Anyway, the component has been refactored up to a degree where handling selections and pending selections has been greatly improved and simplified, along with other changes to the UI so the component looks like a "real" Ext grid. This changes will make it into the 0.2 branch before backwards compatibility will be broken (due to Ext 2.2 support).
Thank you for your fixes. Especially thanks for fixed the problems if there were less records than could be displayed.
Do you have any plans to implement a fix for the scrolling bug in the next version or is that a lower priority? For us it's the highest priority so we cannot use the actual version because of that bug. We're using Ext 2.2. You said a week before you would implement it into version 0.2. Am I right that you are working on it?
But anyway we wait then until end of september. Thank you for your support.Ext2.2 support is scheduled for V0.2.
Is it possible to have pagination in LiveGrid? If the total count is very large (greater than 10000), it will be hard to control the scroll bar to navigate to a particular record.
In normal GridPanel, a large page size will cause a performance problem. But in LiveGrid only the visible rows will be rendered. So it seems that the combination of LiveGrid and pagination will be the ideal solution.
thanks for this "live grid". Great works!
Is it possible to lock the first column and activate horizontal scroll only for the other columns?