sliderbug or me being stupid again...?

[Michael J. Lew]

At 6:39 PM -0400 28/7/04, Wouter wrote:
>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: michaell at unimelb.edu.au
**