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. Tom 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.schi...@bestsolution.at> wrote: > >> Hi, >> >> 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. >> >> Tom >
