Re: [Tile-dev] Odd error in ttk::entry/ttk::scale

[Joe E. <jen...@fl...>]

Joey Mukherjee wrote:
> Thanks for the help with the treeview!  Adding the break solved it
> since I was, as you surmised, destroying the treeview each time.
>
> Anyway, I wanted to post another oddity I had with Tile, but it would
> be hard to describe so I thought a test case would be easier.  What I
> have is a simple time dialog and when I adjust the day of year, I
> want the month/day of month to auto computed and placed in a scale/
> entry pair.  Seems simple enough and it worked fine when it was not
> tile.
>
> Now that I have tile, when I slide the scale, I can only move a
> little bit before it jumps to the end of the slider!
> [...]
> This is with the 0.7.6 of tile.  You should be able to do a wish
> test.tcl and then slide the "Day of Year" scale until you get to day
> 31.  When it hops over day 31, it is supposed to go to month 2, day
> 1.  Instead it hops over to 12/31, day 365.

OK, here's what's going on:

Start with Day = 31, Month = 1, DOM = 1, and increment the Day slider.

This calls [ScaleChange ... 32] (the scale's -command).
Which calls [SetEntry ... 32]
Which calls [EntryChange StartDay 32] (via the entry's -validatecommand)
Which calls [UpdateString StartDay] (among other things).

Now here's where it gets interesting.  [UpdateString StartDay]
computes Month=2 and DOM=1 from Day=32, then calls
[SetScale ... $Month] and [SetScale ... $Day].  [SetScale]
compares the current value with the new value and returns
immediately if they're the same; but this time the Month
has changed from 1 to 2.

So it calls $scale set $value;
Which calls [ScaleChange ... 2] (this time for the Month slider),
Which calls [SetEntry ... 2],
Which calls [EntryChange StartMonth 2],
Which calls [UpdateString StartMonth].

Now we have Month=2, and DOM is still 31.  [UpdateString StartMonth]
computes a new day-of-year (62) and calls [SetScale] to set the
StartDay slider, and we're back where we started, this time
with Day = 62.

The process eventually reaches a fixed-point, and the recursion
terminates in [SetScale].  You can see this in action with:

    proc entered {cmd op} { puts "ENTERED: $args" }
    proc watch proc { trace add execution $proc enter entered }
    watch TimeDialog::ScaleChange

Starting from Day = 31 and incrementing the slider, we get:

    ENTERED: TimeDialog::ScaleChange StartDay 32.0
    ENTERED: TimeDialog::ScaleChange StartMonth 2.0
    ENTERED: TimeDialog::ScaleChange StartDay 62.0
    ENTERED: TimeDialog::ScaleChange StartDOM 1.0
    ENTERED: TimeDialog::ScaleChange StartDay 32.0
    ENTERED: TimeDialog::ScaleChange StartDay 366.0
    ENTERED: TimeDialog::ScaleChange StartMonth 12.0
    ENTERED: TimeDialog::ScaleChange StartDay 335.0
    ENTERED: TimeDialog::ScaleChange StartDOM 31.0
    ENTERED: TimeDialog::ScaleChange StartDay 365.0


So what I wonder is not "Why doesn't this work with Tile",
but instead "Why did this work in the first place?".

(The answer probably has to do with the fact that core [scale]
widgets call their -command at strange times and for strange
reasons, usually in an idle handler.  It's likely that deferring
the ScaleChange call allows the process to stabilize sooner.)


--Joe English

  jen...@fl...