Tk Source Code

Not sure if this qualifies as a bug ...

I want to configure the allowed range for a spinbox from 
10 to 20:

   % info tclversion
   8.4
   (bin) 2 % spinbox .s
   .s
   (bin) 3 % .s configure -from 10
   -to value must be greater than -from value

As the defaults for Tk's spinbox -from and -to are both 
zero, it follows that I'm forced to first change the -to 
value followed by the -from one, or change both at 
once. My impression is that the defaults should be from 
MININT to MAXINT or some such. Notice that the 
defaults for Tk's scale -from and -to are 0.0 and 100.0, 
respectively.

Other solution suggested in comp.lang.tcl was the 
following: rather than bailing out, autoadjust 
the "other" end to be equal to the one currently set. 
(except if both are set in one go)

Merged to trunk (8.7) only.

This is my conservative decision in full agreement with myself since no other voice was raised.

I have been mumbling on this quite a bit and I think there is another way, that was not yet mentioned AFAIK: if "-from" is larger than "-to", just swap their values before using them.

With this:
  - no error anymore when saying  "spinbox .s -from 10": -to receives 10, and -from receives the default from -to (i.e. 0).
  - programmer may now specify -from and -to in any order, in separate instruction lines (i.e. in several steps) or in the same configuring statement
  - no complicated auto-altering of direction since in fine we still always have -from <= -to

I have proposed this fix in branch bug-841280ffff.

The only backwards compatibility concern I have is if a script relies on the error that used to trigger when -from is greater than -to. Despite I cannot find such a use case, I cannot 100% exclude this possibility. Is it really an issue in your opinion as far as merging the fix in trunk is concerned?

Logged In: YES 
user_id=72656

See also 1439266

Logged In: YES 
user_id=662619

I don't understand the argument you use to not change the
defaults. Using the spinbox with a list via de -values option
simply dismisses the -from, -to and -increment options, so 
that their defaults would no longer apply.

Again, in my opinion, changing the -from/-to defaults (may
be together with those of [scale]) is the best option.

I've been thinking about your idea of auto-altering the
direction,  but I don't come up with any alternative I
really like. The best option I can think of along these lines
is to allow -from > -to and using the absolute value of
-increment so that pressing up always goes from -from to
-to, but that's incompatible with the (arguable) current
behaviour that -increment may be negative so that pressing
the spinbox up button *decrements* the spinbox value. 
Notice this behaviour would reduce the gap between the
spinbox and scale widgets which, albeit both having the
-from/-to concept, they currently behave quite differently.

Logged In: YES 
user_id=72656

But the example of inconvenience is impractical because a
user should just write:

.s configure -from 10 -to 20

and there is no error, even though the from comes first in
the list of options.  The reason to not change defaults is
because of the overloaded purpose of the spinbox (that
either numbers or a list can be used).  We could consider a
smarter -from/-to that auto-alters direction, but a patch
for that would be appreciated.

Logged In: YES 
user_id=662619

I agree that magically changing the options may not be a 
good option, but what about changing the -from and -to 
defaults which are currently both set to zero? Notice that 
those of Tk's scale are 0.0 and 100.0!

This problem has shown up because we are building derived 
widgets using [incr Tk]. In that case, one does not have 
precise control on the order in which options get propagated 
to the base widget. For our extended spinbox widget we have 
been forced to add quite a bit of logic to work around this 
behaviour of Tk's spinbox.

I find it "inconvenient" that
   spinbox .s
   .s configure -from 10
   .s configure -to     20

throws an error while setting -from to 10, while
   spinbox .s
   .s configure -to     20
   .s configure -from 10
works as expected. That reminds me of context-sensitive Perl.

Notice that Tk's scale allows from > to: the direction of 
increment of the scale changes. 

May you please reconsider your position?

Logged In: YES 
user_id=72656

As it's doc'ed, I'd like to leave this as is.  It's just
another option for the user to specify, and to magically
change the options around might confuse users later
requesting the actual value.