I need to have my memory checked - I just went back and looked at the source code (hadn't been in there in almost 2 years), and you're right: it's not the issue I described, and it is an issue that should be fixed in the platform.
Can you file a bug in JIRA so this can be tracked and fixed? In the meantime, if you can work around this by adjusting the actual width of the scroll bar (I don't know your surrounding layout, but perhaps it'd be as simple as adjusting its preferred width) such that the scroll bar units divide evenly into pixel units, that's the workaround. The reason ScrollPane doesn't have this issue is because its scroll bar units always divide evenly into pixel units since they represent pixel units :-) Sorry for the confusion, -T On Fri, Oct 22, 2010 at 9:44 AM, Kamil Toszek <[email protected]> wrote: > Hi Todd, > But from what I understood from your answer, setting unitIncrement to 1 will > solve this problem in every case right? Well I set it to 1 and I still have > this gap. Maybe there should be a boolean flag (or default behavior) which > handles this in the corner cases, because even in your example if you set > values like you provided and assuming end=10 is inclusive, then maximum what > we can get is 9 - value 8 + extend 1, thus we well never reach the end > value. Am I right? > regards > Kamil > > > 2010/10/22 Todd Volkert <[email protected]> >> >> Hi Kamil, >> As funny as this sounds, it's by design. It's up to the caller to make >> sure that the value+extent will equal the end of the scroll bar on the right >> side (given the unit and block increments). The primary caller of >> ScrollBar, ScrollPaneSkin, ensures this, so most callers never get exposed >> to it, but if you use ScrollBar manually, you'll need to handle this. >> To put it another way, ScrollBar takes its values (unit and block >> increment, scope, and value) literally, so if you have a scroll bar with >> {start=0, end=10, value=8, extent=1, unitIncrement=2}, there's no way to >> increment it to the right (because that would push it past the end), and yet >> there'll be a 1-value gap on the right. The solution would be to either >> lower the unitIncrement to 1 or to change the end such that it divided >> evenly. >> I thought about this a lot when building ScrollBar - should it allow >> itself to scroll less than the unitIncrement when it gets to the end in >> order to prevent this from happening? I decided that it should not and that >> the caller should set up the scroll bar in such a way as to not let this >> happen. However, I'd be willing to revisit that decision... >> Cheers, >> -T >> On Fri, Oct 22, 2010 at 8:52 AM, Kamil Toszek <[email protected]> >> wrote: >>> >>> Hi, just digging the thread up. >>> If I didn't write about my problem clearly enough, just let me know. >>> >>> regards >>> Kamil Toszek >>> -- >>> View this message in context: >>> http://apache-pivot-users.399431.n3.nabble.com/Scroll-Bars-tp1746186p1752359.html >>> Sent from the Apache Pivot - Users mailing list archive at Nabble.com. >> > >
