ScrollBar & visibleAmount & value
tom.schindl at bestsolution.at
Tue Sep 3 05:20:30 PDT 2013
Well like I said Swing & SWT do interpret this different!
To me the value always meant to the upper ending of the thumb. If you
think about edge cases of 99 (value still goes from 0..100) and 100
(value can 0 only).
Anyways from your answer I guess the current behavior is correct and no
ticket needs to be filed and I have to do the calculation from below to
match API contract of the library.
On 03.09.13 01:40, Richard Bair wrote:
> Oh interesting, I always considered visibleAmount as being an independent state that affected the size of the scroll bar thumb, but not really anything more. The reason why was for virtualized uses like with ListView where the height of the thumb might change as you scroll.
> On Sep 2, 2013, at 1:38 PM, Tom Schindl <tom.schindl at bestsolution.at> wrote:
>> Before fileing a bug I wanted to post here because maybe I get this
>> completely wrong.
>> Say we have have a scrollbar with min = 0 & max = 100 & visualAmount =
>> 50. I would have expected like in Swing & SWT that the maximum value of
>> the scrollbar is 50 (=max - visualAmount) but the value is still 100.
>> Is this desired or an oversight? I can work around this problem by
>> calculating the value back using ((max-visualAmount)/max)*value but like
>> I said this is unexpected when coming from the other toolkits.
More information about the openjfx-dev