unset , a built-in Tcl command, removes one or more variables.
It is an error for the variables to not already exist, the name to be illegal, etc. This error can be suppressed with the -nocomplain option.
A trace on the variable can resurrect it.
DKF: In 8.6, unset is bytecode compiled. (And don't use catch {unset foo}; the operationally-equivalent unset -nocomplain foo generates much better bytecode.)
In retrospect, unset should have been designed so that it was not an error to In retrospect, unset should have been designed so that it was not an error to unset a variable that didn't exist, in which case -nocomplain would not have been necessary. Unsetting a variable will remove all the traces on it. If there are any variable unset traces, they will first be called. Proc-local variables are implicitly unset when the proc returns. By using an unset trace, we can do sneaky things:
** Misc ** [Erik Leunissen] on [comp.lang.tcl] 2002-10:
Well, I've been bitten by this one on a *regular* basis, but not on a
*frequent* basis. So infrequently, that I tend to forget about the issue,
and once it happens again, it takes me by surprise and I need hours to find
the cause of evil, which I'll explain:
The following happens when you bind a variable to an entry widget
through the `-textvariable` option and subsequently issue [unset
textvariable] :I'm not sure. Perhaps somebody else can elaborate on this ...
contents of the entry widget to the textvariable. (If it has been
unset for a short moment, it is recreated)
So what's the recipe then?surprise the next time.
For the coming releases of Tcl (still in CVS), you can also set an unset trace on the textvariable, and let the trace handler do the above step one and/or two. For current releases this will not yet work because of a (recently fixed) bug. package require lambda proc test {n cmd} { unset , a [Tcl