Agreed. I can suggest two simple changes that seem as though they would
make sliders work out of the box:
1) Change the default lineIncrement to 0 for slider style objects
2) There appears to be an engine bug with the number of ticks displayed
(at least on MacOS X). There is one too few. For example, for a slider
with values from 0 to 100, pageInc = 10 and lineIncr = 0 (as described in
this thread), it displays 10 ticks. There should be 11:
0,10,20,30,40,50,60,70,80,90,100, My guess is that somewhere the engine is
doing something like:
numTicks = (maxValue - minValue)/(pageIncrement - lineIncrement)
This seems intuitively ok at first (100 divided by 10!) but it should
actually be the above plus 1, since you want ticks at both the min and max
values.
As it is now, what you get is a slider that stops on 10,20,30,etc but the
ticks marks are actually at 11,22,33,44,55,etc - which looks very awkward.
I'll BugZilla #2 as an engine bug unless someone else sees something here,
but as far as I can tell it makes it impossible to properly display a
slider, since paging left and right misses the ticks completely!
- Brian
Well done Brian. Yes, setting the (invisible) lineIncrement property
to zero fixes the numbers.
I didn't notice that the little ticks were wrong. I don't know how to fix
them.
Your initial comments regarding a new user are exactly my sentiments.
There are a couple of bugs in scrollbar objects in addition to such
unexpected behaviour. I would like to see them cleaned up
substantially at some stage. They are awkward to use in any
quantitative way because their lineInc, pageInc and numberFormat
properties are all interlinked.
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
