By default the value of a scale widget is changed either
by dragging the slider or by left-clicking in the trough. The
increment by which the left-click changes is the same as the
resolution, by default one unit. You can increase the increment
by which a click moves by increasing the resolution value (which
decreases the resolution in the normal sense). However, sometimes
it is convenient to have a finer resolution available while also being
able to move in larger increments. A solution is to bind to
<B3>, which is by default unbound, a larger movement.
This procedure moves by the specified multiplier k times
the resolution of the scale. 

 proc ScaleMoveBigIncrement {w k x y} {
    set part [$w identify $x $y]
    switch -exact -- $part {
        trough1 {
            set dir -1;
        }
        trough2 {
            set dir  1;
        }
        default {
             return
        }
    }
    set Resolution [$w cget -resolution]
    set CurrentValue [$w get]
    set Delta [expr $dir * $k * $Resolution]
    $w set [expr $CurrentValue + $Delta]
 }

The coordinates x and y are supplied by
Tk when the binding is triggered. w and k are,
from the point of view of the individual binding,
constants. They represent the scale widget and
the desired resolution multiplier. You supply
them when you create the bindng. A typical
binding might look like this:

 bind .play.vol <<B3>> {ScaleMoveBigIncrement .play.vol 5 %x %y}

Of course you can bind to some other event if you wish to.


[WJP]

[ARR]

I think here is an unwanted behaviour of the scale widget! I want to use a scale to define values from 3 to 13 in increments of 2. So I define the scale like this:

   pack [scale .s -orient hor] -fill x
   .s configure -from 3 -to 15 
   .s configure -tick 2 -resolution 2 

What I get is a scale changing values from 4 to 14 in increments of 4. This is not what I expected. The reason is the -resolution option which causes the scale to change the -from value to a multiple of the resolution. Any comments? Is this a tk bug or can I do it another way?

[WJP] 
I would call this a bug since the observed behavior is not in agreement with the documentation and since the desired behavior is perfectly reasonable.

----
[category widget]