After dealing with a lot of issues related to ListView usage for the past few years I’ve stumbled upon one which did not require me to change any source code to fix.
Issue was with scrolling, where if your framerate is low enough and you are able to scroll so fast you skip a tick that would handle that otherwise, you’ll end up being unable to scroll to the end of the list or sometimes even stay stuck in the middle with half of “last” entry showing. At first I thought it’s possible to happen only with items with different height, but that’s not true.
If you enable fixed offset along with animation though, you’ll bypass all of these issues caused by list view’s way of handling the scrollbar. Interesting thing is that if you drag the scrollbar you’ll never be stuck. It happens only when using mouse wheel because mouse wheel events are handled by the list view which then tries to update scrollbar, while dragging is handled by the scrollbar alone.
All of this comes down to relying on layout geometry which is often very wrong (usually you have the real data only for the next tick and the view doesn’t update itself afterwards, if you’ve worked with scale boxes you know), but enabling fixed offset is making list view use actual items instead of entries and when you enable animation you’ll get the smooth transition.
Even if visually the scrollbar doesn’t know what to do sometimes and gets resized all over the place, at least you are still able to get to the end of the list independently of framerate.
IDK how this behaves with entries changing size, but fortunately I’m not using those in places where user could scroll that fast, but maybe it works just the same (hopefully).
I just wanted to share this trick that helped me so much and using it as one more ++ for a request to refactor list view class. It has much too many quirks.