Quote Originally Posted by wysota View Post
So which approach did you finally take?
I fixed what was there. The cache class did not fit the data flow and given the follow on description of each leaf becoming a row for the flat proxy model I'm kind of glad we didn't try going down that road.

Basically, the flick scrolling tells the model to get more data when it hits the end of the scrolling region as before, but now when we get that data we don't add and remove, instead we reset model then reset the hidden scroll bar to the middle of its range, or wherever, so we can continue scrolling. The main database level scroll bar only smoth scrolls over the range of currently loaded data which is a tiny fraction of its range. Once the user exceeds that amount nothing happens until they let go of the slider. We get the current slider value and have the model reload itself using that as the starting point.

It may not seem elegant, but you don't want to do the IO for Gigs or TBs worth of binary data the user doesn't give two hoots about since they are trying to position a long way back.

I realize some people thing Apple does amazing design, but I have to tell you, flick scrolling sucks. Just trying to get 100 records back on a little embedded screen when each record expands N-hundreds of rows absolutely blows. Carpel Tunnel hear I come!