Some weird behavior or am I doing something wrong?
recipe: A scrollbar, style set to scale/slider, start value 1, end value 10, show value true A button with the script:
on mouseUp put the thumbpos of sb 1 into tX repeat with i = 1 to tX put 0 into item i of tC end repeat put "thumbpos:" && tX && "output:" && tC end mouseUp
Try different positions of the slidebar. Look at the output with the thumb in the region just before the value shown changes.
No, not YOU being stupid, the slider is stupid. I have to admit that that alleged stupidity of the slider is my opinion and it is not shared by Scott Raney (see bug #347).
Set the numberformat of the slider to "0.00" and look at the results. You can get it to work how you might expect by using round(the thumbposition) in your script. But there is more to it...
Sliders and scrollbars are far more difficult to work with quantitatively than you might think. The pageIncrement property doesn't determine the increment obtained when you click on the grey bit, it is really the pageInc minus the lineInc. The default lineInc for a new slider object is set to 0 (you can't see it in the object properties inspector but you can query it or set it with the message box). However, it changes if you change the numberformat ("Value format") of the slider! Thus if you have a slider with the numberformat set to show some decimal places you will see that clicking in the grey area of the slider gives you a change of value that is LESS THAN the pageInc ("On bar click") value. Of course, how much less than the expected value depends on the particular numberformat. I find this situation to be awkward every time I try to use a scrollbar or slider object.
Just yesterday I posted this to the Improve-rev list:
At 3:27 PM +1000 28/7/04, Michael J. Lew wrote:
Did you know that the change in thumbposition that occurs when you click in the grey area of a scrollbar object is NOT the pageIncrement? It is actually the pageIncrement minus the lineincrement.
That is not new with the beta, and it is not what the documents say but you can confirm that quite simply:
Making a new scrollbar object, set its endValue to 100, its startValue to 0, its lineInc to 1 and its pageInc to 10. Now give it a script On mouseUp; put the thumbposition of me; end mouseUp.
Now click away and see that the increment is 9, not 10.
I posted this as a bug a long while ago (see BZ #347) but was told that it is not a bug because the GUI standard has it that a page should scroll to have the new first line the same as the previous last line (i.e. the page increment is a page minus one line). However, the documentation has not been corrected.
I think that the argument for having page increment not equal to the pageInc is very weak. It doesn't seem sensible to have to work around the odd values every time we make a scrollbar to control something just to make the conformance with GUI standards for scrolling pages of text automatic. I am doubly-sure that the situation is bad because most often when text is being scrolled it is via a scrolling field rather than a separate scrollbar object and so it should be possible to have scrollbar objects behave well and fields behave differently.
What do you think? Should the behaviour of scrollbar objects be changed so that the pageIncrement property is what it says or should the docs be adjusted to reflect the confusing reality?
-- Michael J. Lew
Senior Lecturer Department of Pharmacology The University of Melbourne Parkville 3010 Victoria Australia
Phone +613 8344 8304
** New email address: [EMAIL PROTECTED] ** _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
