I think it is clear now, thanks
.
From what I understand you cache the 0-50 viewport (or any other initially) in a separate place.
What you should do is keep in the viewport all rows that you use on client.
So instead of
- Code: Select all
fs.loadRecordsAsync(fs.viewPort.startIndex+fs.viewPort.size,fs.viewPort.size)
you can do
- Code: Select all
fs.loadExtraRecordsAsync(50)
so your viewPort will contain after the first scroll rows 1-100. In this way you will see changes comming in for all 100 rows when they happen.
The way you had it, the property requested viewport 50-99 and that is what it got. But you are interested in changes for all rows that are on client.
You could I guess if you really want to cache the rows in a different place and keep the viewport small, when you do sort, reload the whole thing - so manually request a viewport change. But it doesn't help much, because the first 50 rows that are no longer in the viewport but are shown could change due to changes in other forms, or maybe in other clients as well, not just due to sort. And I guess you want to detect that as well.
You can listen for changes by shallow watches on viewport size, startindex, serversize, ... if you need them and deep (or collection) angular watch on viewport.rows or on each row/cell (if you want to know more precisely what changed); as a note - in Servoy 8.1.3 there is an undocumented listener you can add to the foundset property to get row updates (it doesn't notify of full viewport changes or other changes, just when only some rows are removed/added/updated); this listener is used by servoy-extra table to get rid of some deep watches and do granular updates to the UI in some scenarios. But you shouldn't use that yet because it will change; I am currently working on improving and then documenting that listener for 8.2 (cases
SVY-10781 and
SVY-10706).