The following occurs on LINUX only. I tried many Linux
systems with differing O/S versions. All failed. May be a
compiler bug, but I'll report and see if anyone else has
seen this problem.
With the -resolution parameter set to a decimal value
(.1 for example) , the widget triggers and executes
the -command when the cursor enters and leaves the
the slider area (and with tk_strictMotif set, the entire
widget).
The problem appears to be that TkRoundToResolution()
returns a value with digits way beyond the end of the
specified resolution. Then when -configure events
occur, this value is then rounded again producing a
slightly different value, so the command is triggered,
even though the event was a simple background change
as the result of an Enter/Leave event.
My solution (HACK), was to use the "new" value
calculated within TkRoundToResolution() within a dummy
print statement. I have no idea why this removes the
extra junk, but it does, and the results are that the
scale widget works as it should.
I've attached a two line example which demonstrates
the problem. When the example starts, things work as
expected, but once the slider has been moved. Moving
the cursor thru the slider area triggers the command.
Example to demonstrate the problem
Logged In: YES
user_id=80530
Sounds a bit like Bug 220665
but that was fixed long ago.
Logged In: YES
user_id=80530
Sounds even more like Bug 220265
where a compiler bug was diagnosed.
Logged In: YES
user_id=80530
Well, I'd filled out a long
comment about being unable
to reproduce this, and blaming
buggy compilers, and then
I reproduced it.
Reproduction using gcc 2.95.3
to compile. All default configuration
options for Tcl/Tk.
Run the demo script. Move the
slider. Then move the cursor
back and forth over the "thumb"
control of the slider.
Logged In: YES
user_id=80530
Can the original reporter
please reveal what compiler
he used when he discovered
this problem?
Logged In: YES
user_id=80530
I edited the Tk Makefile to set
CFLAGS_OPTIMIZE to use
optimization flag -O0 instead
of -O
This made the buggy behavior
go away. That's an effective
workaround, and indicates it
is likely this report is a
duplicate of Tk Bug 220265.
Dropping priority since we have
a workaround. Keeping open
in case we can effectively
re-order the code so that even
buggy compiler optimizers can't
break it. :)
Logged In: YES
user_id=80530
A comp.lang.tcl post reports
this problem using
ActiveTcl 8.4.6 on Linux.
What compiler (& options)
was used to build that?