inconsistent scroll position after listMoveTo about brick HOT 9 CLOSED

I'll look into this. The thing about scrolling is that it isn't in the widget state at all; it's in the renderer (for reasons that I can go into). So you can get at that information, but only in event handlers. The only state related to scrolling that is stored in the List is the list selection index. Then when the list is rendered, that selection index is used to tell the renderer which element in the list should be scrolled to, and the scrolling state is managed by the renderer after that.

I'm curious: when you see this difference in behavior in listMoveTo, is there also a difference in the number of list items? And is the number of list items less than the height of the screen?

from brick.

After doing some testing of my own I can't reproduce this, so any details on your situation would be especially helpful.

from brick.

I'm also curious about when in the program this occurs: do you repopulate the list occasionally?

from brick.

I populate the list each time the user enters this screen, and move the selection to the end immediately after that. On entering the screen, sometimes the selected item is at the bottom of the terminal, and sometimes it's at the top (it's the only line showing). It happens both with more and less elements than fit on the screen, and it varies somewhat on successive runs of the program and even successive entries to the screen during the same run (with no data changes).

I have since flipped the sort order, so currently I start at the top and this is affecting me less.

On Aug 20, 2015, at 8:56 AM, Jonathan Daugherty [email protected] wrote:

I'm also curious about when in the program this occurs: do you repopulate the list occasionally?

—
Reply to this email directly or view it on GitHub #11 (comment).

from brick.

In that case, the reason for the behavior you are seeing is almost certainly that the old scrolling state of the list's viewport is affecting the scrolling behavior you get when you call listMoveTo. You are reinitializing the list but the old viewport state (its vertical offset) is not being reset to zero, so scrolling changes triggered by listMoveTo are not going to behave consistently. I think the solution is to add functions to EventM that allow you to reset a viewport, but I'll have to think about whether that's the best approach.

from brick.

Assuming my theory above is correct, you can get the behavior you want by pulling the latest commits and then, in your event handler, where you repopulate your list, also do this:

vScrollToBeginning $ viewportScroll (listName someList)

from brick.

This updates the viewport state (same as hitting Home, essentially) so that when the list is re-drawn, the item you moved to is at the bottom of the screen.

from brick.

On Aug 21, 2015, at 8:31 PM, Jonathan Daugherty [email protected] wrote:
This updates the viewport state (same as hitting Home, essentially) so that when the list is re-drawn, the item you moved to is at the bottom of the screen.

Thanks! That seems to be working well.

from brick.

If this is working as desired, please close this issue (or let me know what else I can do).

from brick.