Tk Library Source Code

To deal with renaming of objects snit provides the 
command [mymethod] to create code which can be 
given to callback handlers.

The generated code essentially refers to the variable 
$Snit_instance in the unchanging private namespace of 
the object, which contains the current name of the 
intance = instance command.

Example:
     mymethod foo
generates
     "$Snit_instance foo"

This is variable reference is a bit problematic. The code 
executing the callback __must not__ any list command 
when adding additional arguments to the callback. Which 
is usual. The moment a list command is used, for 
example [linsert], or [lappend] to build up the full cllback 
command the variable reference will be quoted in braces, 
and the final command will look like:

     "{$Snit_instance} foo arg1 arg2 ..."

[eval]'ing this fails.

Example stacktrace

invalid command 
name "$::ttable::ttable::Snit_inst1::Snit_instance"
    while executing
"{$::ttable::ttable::Snit_inst1::Snit_instance} 
NColChanged 0 3"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [linsert $options(-ncolcommand) end 
$oldncols $ncols]"
    (procedure "Snit_configure-data" line 42)
    invoked from within

You see how the command is constructed, and the 
additional quoting generated by this.

The big problem is that the usage of list commands to 
construct an eval'able callback is the usual way of doing 
this.

Logged In: YES 
user_id=372859

As the comment below says, the actual fix for this problem was 
committed over a year ago; and since then we've made the decision that 
it's OK for snit types and widgets to depend on Snit run-time code (this 
was a space issue).  So this RFE is no longer needed.

Logged In: YES 
user_id=75003

Conversion to RFE complete.

Logged In: YES 
user_id=75003

Patch committed.

This report will now change into an RFE. The handling should 
be moved into the type/instance namespace to allow 
types/objects in the future to run independent of snit itself.

File Added - 56218: diff.snit.txt

Logged In: YES 
user_id=75003

Here is a patch.