Tk Source Code

My code wasn't working as I expected and I couldn't see what I was doing wrong. I finally found some strange behavior from ttk when I reduced the code to:

    ttk::button .b
    set state [list invalid disabled]
    puts [join $state]
    .b state $state
    puts [join $state]

The first puts prints "invalid disabled", the second prints the list states in reverse order; "disabled invalid". So the value of the 'state' variable has changed, even though it was passed by value. I don't think that is in line with how Tcl is supposed to work.

Using tcl::unsupported::representation I found out that the internal representation of the value is changed from a list to a StateSpec. A StateSpec is a set of bit flags. It can be converted back to a list, but it uses a fixed order for the states, which may differ from the original list.

Using join is important, because if you just puts $state the list stays in the original order. I presume that happens because that causes a string representation to be generated. This first threw me while trying to debug.

When I figured out the cause of the problem, I could work around it by doing a dummy string length $state. Or better, build the state variable with the states in the order ttk expects them.

While I found the problem on Tk 8.6.16, I checked that it is still reproducible on the current trunk.

Yes, the internal type of a value can change. If you run llength on a value with an internal type of dict, its internal type is changed to list. That's fine as long as the value doesn't change. Now please let's get back to the original problem of this ticket.

Let me explain it:

• Given variable X which has value V of internal type T
• A widget gets the value V assigned
• By the assignment operation V's internal type is change to U
• At the end variable X has another type U

Is this expected outcome?

Jan, let's see the fix. The point remains that the object type is changed (no immutability) which can cause interesting unexpected effects. The pixel stuff might well be fixed in 9.0 (is it really? cf. immutability) but how to prove that in any other object type implementations where similar problems may or may not exist? BTW: since when did we abandon 8.6?

Schelte, my point is that similar to your problem description the object type of the variable is changed with unintended consequences on the further usage of the variable. This due to some kind of EIAS violation, isn't it?

Sorry Christian, I don't see the relevance to this ticket. Sure, the -border option returns something else than what you set it to (at least when run from a script, interactively it works fine). But the value of variable 'x' remains unharmed.

Or make the conversion from the very start on on a duplicated object such that the original object remains unmodified.

Sorry Schelte, I've pasted the wrong code, try this one:

  tk scaling 1
  set x 10m
  . configure -border $x
  puts [. cget -border]
  puts $x
  tk scaling 2
  . configure -border $x
  puts [. cget -border]
  puts $x
  set x [string range X$x 1 end]
  . configure -border $x
  puts [. cget -border]
  puts $x
  # more fun
  set x [string repeat 1 50]
  . configure -border $x
  puts [. cget -border]
  puts $x
  set x [string repeat 1 500]
  . configure -border $x
  puts [. cget -border]
  puts $x

Oh sorry, right, that was it (running the commands in interactive mode). Can repro now. Even 8.6.9 shows the issue.

Christian,

While the second error message is a bit unexpected, I don't see any changing of variables under the hood when running the commands you mentioned. That was the main point of my bug report.

Are you running the commands interactively? In that case, the REPL will print the result of set state [list invalid disabled], generating the string representation. That circumvents the problem.

To run interactively, use:

    ttk::button .b
    set state [list invalid disabled];list
    puts [join $state]
    .b state $state
    puts [join $state]

Hmmm... I'm not reproducing what Schelte is reporting. This is on Windows, MSVC, debug build, with either the tip of the trunk branch, the tip of core-8-6-branch, or the core-8-6-16 tag. For me the two puts both spit "invalid disabled".

Schelte,

I believe you've hit a nice little pothole while driving on the Tk road which is partially filled with a can of worms. You were on the Ttk lane, but it seems even more common, e.g.

  tk scaling 1
  set x 10
  . configure -border $x
  puts [. cget -border]
  tk scaling 2
  . configure -border $x
  puts [. cget -border]
  incr x 0
  . configure -border $x
  puts [. cget -border]
  # more fun
  set x [string repeat x 50]
  . configure -border $x
  puts [. cget -border]
  puts $x
  set x [string repeat x 500]
  . configure -border $x
  puts [. cget -border]
  puts $x

Could be that results differ between 8.6 and 9.0 (didn't test the latter).

Could even be that this requires further discussion regarding intentions, expectations, and consequences.