http://www.purl.org/tcl/home/man/tcl8.5/TclCmd/trace.htm 
----
What are some of the uses for trace?  Well, see [Traces] for some wiki info.

   * Communication between parts of a GUI and the internal state of the app. (Simplified [MVC], observer). In general communication between different parts of an app without coupling them strongly.

   * Simple constraint computation for a number of variables ("if this flag is on and that one is on, then no other is allowed to be set", and some such).
   * [Canvas] text items bound to a variable, dynamically updating
   * Debugging - call a proc when a variable is modified (detect setting from wrong routine).
   * Trace works in Itcl [Itcl trace] but not quite trivially.

----
''A small example to illustrate the order of processing -- [JCW]''

  proc tellme {id a e op} {
    puts "  $id a=$a e=$e op=$op\
                ax=[info exists ::$a] ex=[info exists ::${a}($e)]"
  }

  proc do {args} {
    puts "<$args>"
    uplevel $args
  }

  trace var a wu {tellme array}
  trace var a(1) wu {tellme element}

  puts [trace vinfo a]
  puts [trace vinfo a(1)]

  do set a(0) zero
  do set a(1) one
  do set a(2) two
  do unset a(0)
  do unset a(2)
  do unset a

  # output is:
  #
  #   {wu {tellme array}}
  #   {wu {tellme element}}
  #   <set a(0) zero>
  #     array a=a e=0 op=w ax=1 ex=1
  #   <set a(1) one>
  #     array a=a e=1 op=w ax=1 ex=1
  #     element a=a e=1 op=w ax=1 ex=1
  #   <set a(2) two>
  #     array a=a e=2 op=w ax=1 ex=1
  #   <unset a(0)>
  #     array a=a e=0 op=u ax=1 ex=0
  #   <unset a(2)>
  #     array a=a e=2 op=u ax=1 ex=0
  #   <unset a>
  #     array a=a e= op=u ax=0 ex=0
  #     element a=a e=1 op=u ax=0 ex=0

----
On news:comp.lang.tcl, [CLN] answers [Erik Leunissen]'s question:
Erik Leunissen wrote:
 > The following passage from the man page to the trace command is
 > mystifying to me:
 > 
 > "If an unset occurs because of a procedure return, then the trace will
 > be invoked in the variable context of the procedure being returned to:
 > the stack frame of the returning procedure will no longer exist."
 > 
 > I've read it again and again; I can't imagine how a procedure return
 > affects/causes an unset.
 > ...


    proc foo { } { 
       set x 1
       trace variable u x {some code here}
    }

When foo is invoked, x is created (locally), has a trace associated with
it, then becomes unset as foo exits.
----
On news:comp.lang.tcl, [Kevin Kenny] answers someone wanting to link a C variable and a Tcl variable, and have a Tcl proc invoked when the C code modified the variable:


 Look in the manual for Tcl_UpdateLinkedVar.  The Tcl engine has no way of
 telling that you've changed the variable in C; if you call Tcl_UpdateLinkedVar,
 that tells it your value has changed, and it fires the traces.
----
'''Simple file I/O in traces:'''
 trace var stdout w {puts stdout $stdout ;#}
 trace var stdin  r {gets stdin  stdin   ;#}
The variables are named like the file handles. Little demo, that waits for input and prints it capitalized:
 set stdout [string toupper $stdin]
----
Trace programming's hazardous--it too often presents mysteries to unfamiliar programmers.

Traces are like [widget]s and [image]s in that they are resources that can be leaked and/or
need clean-up.  Counter-intuitive results sometimes arise because traces are additive rather
than substitutive; a particular trace can fire a whole chain of commands.  To wipe the global
space clean of traces,
    foreach variable [info glob] {
        foreach pair [trace info variable ::$variable] {
            foreach {op traced_command} $pair {}
            set op [string range $op 0 0] 
            trace vdelete ::$variable $op $traced_command
        }
    }

----
"It's easy to constrain the depth of [recursion] by having the trace
procedure look at [[info level]]."  So observes [KBK], in commenting
on use of ''enterstep'' 
[http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=left&th=3af6d6ee32a46154]
----
[male] 2006-01-24: I had the problem, that I wanted to trace the creation of an array element and used the write event. But ... the write event is fired, after the new array element was already created! What's about a new event like "create"? Since a trace may be created on non-existent variables, this could be useful not only for arrays.
----
[Donald Arseneau] Yes, write traces fire after the variable has already been set, so if you want validation of variables' values, in analogy with Tk's [entry validation], then you must maintain shadow copies of the previous values, in order to undo improper settings.
----
[Donald Arseneau] There are several other tricky traps when using traces.  One is that non-array variables give a null string for the array index tag in the trace invocation.  Do not use this as a test for array variables!  Instead, use  
  if { [array exists $varname] } {...
That's because the null string is a perfectly valid array index (it is also a valid array variable name).

It gets worse tracing ''unset'' operations, because all of
  unset a ;# regular var a
  array unset a
  unset a()
give the same parameter list when triggering a variable trace, "a {} u", including a null index string.  The "array exists" test always returns false for the first two cases, and true for the third (even if the null index was the only array element). There is no way for the trace to be sure which operation was performed.

[Lars H]: Hmm... might this be a sign that the format of these parameter lists is not well designed? An alternative would have been to put the operation first and the variable name second, so that there needn't be an index for non-array accesses. Probably too late to change now, though. (Adding a second interface which is just like the current except that it produces parameter lists in a new format is possible, but probably seen as superfluous.)
----
[Donald Arseneau] Another tricky trap is that errors in traces may give error messages, but no context; the only context is for whatever triggered the trace.  Thus, if you ever see Tk error messages like 
  can't set "xv": invalid command name "oops"
    while executing
  "incr xv"
then you should look for a variable trace on the xv variable.
----
[Schnexel] Oh the tricky trace traps! I tried to automaticly update a derivedData array by setting a trace on the parentData array (scenario simplified)... Now I get a surreal result:
        set bla "What happened:\n"

        namespace eval bbb {

                array set lala [list 1 v1 2 v2 3 v3]

                trace add variable ::bbb::lala {read array} ::bbb::tra


                proc tra { args } {
                        append ::bla "\n (TRACE $args)"
                        array unset ::bbb::lala                         ;# also deletes trace (yet the "array" op still fires)
                        foreach {n v}  [list 1 trv1 2 trv2 3 trv3] { set ::bbb::lala($n) $v }
                }
        }

        namespace eval aaa {
                append ::bla "\n\[info exists ::bbb::lala(1)\]==..."; append ::bla ... [info exists ::bbb::lala(1)]
                append ::bla "\n\[info exists ::bbb::lala(1)\]==..."; append ::bla ... [info exists ::bbb::lala(1)]
                append ::bla "\n\$::bbb::lala(1)==...";               append ::bla ... $::bbb::lala(1)
        }

        puts $bla
which gives the output
 What happened:
 [info exists ::bbb::lala(1)]==...
  (TRACE ::bbb::lala 1 read)
  (TRACE ::bbb::lala {} array)...0
 [info exists ::bbb::lala(1)]==......1
 $::bbb::lala(1)==......trv1

So, upon first "read" access of lala, it does not exist anymore, whilst upon second read it is there. Can anybody make sense of this?

[Lars H]: Regarding why the "array" op fires: It it fires at the very [[array unset ::bbb::lala]] where you comment upon this, i.e., before the [foreach], which is consistent with the [trace] manpage (only read and write traces are disabled inside a read or write trace). But why [info exists] reports 0 I don't know... Perhaps some caching issue (the variable that was looked up is not the one that is there when the result is returned)? You'll probably need to read the source to find out.

[Schnexel]: Wrrr... Here´s a simpler example. Array trace is bugged!
 array set ::lala [list 1 v1  2 v2]
 array set ::lala [list 3 v3  4 v4]
 puts "\$::lala==[array get ::lala]"                                   ;# O.K.

 trace add variable ::lala read ::tra


 proc tra { args } {
     puts "    (TRACE $args)"
     trace remove variable ::lala read ::tra

     array set ::lala   [list A trvA  B trvB]
     puts "    within trace:  \$::lala==[array get ::lala]" ;# O.K.
 }

 puts "1st read outside:  \$::lala==[array get ::lala]"      ;# not O.K. !
 puts "2nd read outside:  \$::lala==[array get ::lala]"      ;# O.K.
Output:
 $::lala==4 v4 1 v1 2 v2 3 v3
 reading ::lala
     (TRACE ::lala 4 read)
     within trace:  $::lala==4 v4 A trvA 1 v1 B trvB 2 v2 3 v3
 1st read outside:  $::lala==4 v4 1 v1 2 v2 3 v3
 2nd read outside:  $::lala==4 v4 A trvA 1 v1 B trvB 2 v2 3 v3


----
[Tracing inappropriate variable access]

----
[DKF]: You can debug your scripts using [Whole-Script Tracing].

----
[AM] Using the trace command, I implemented an idea by George Howlett (the author of [BLT])
in pure Tcl/Tk - [An example of data objects]
----
!!!!!!
[Tcl syntax help]
| [Arts and crafts of Tcl-Tk programming]
%| [Category Command] |%
!!!!!!