Re: TK scope "can't read . . . no such variable"

Lionel <lionelv_@xxxxxxxxx> writes:

Is dirList actually used? It looks odd.

No, not at the moment. I was trying to figure out how to get it to work.

I wondered, because
set dirList [list $dir]
looked strange. It might be valid! But it would depend on what
dirList was used for.

-command [$base.clientarea.browseinstalled configure -state disabled]
That should surely be
-command [list $base.clientarea.browseinstalled configure -state disabled]

OK. This is a bit confusing to me. What does list do in this case? It seems
to be used in strange situations

OK, the problem you had originally was your squre brackets tell Tk to
disable that browseinstalled widget immediately. That command returns
a null string, so what you did was to declare "-command {}" (plus the
immediate side-effect).

If you had said
-command {$base.clientarea.browseinstalled configure -state disabled}
it would make sense, but { } give "strong" quoting, so $base would
be saved literally as part of the -command assignment. Then when you
clicked the button, Tk would need to look up the value of $base. That
should work, given that you seemed to set base in the global scope, and
button commands are executed in the global scope. That's why I asked if
the code was executed in a namespace or some other odd context; there
must be some (hidden) reason why $base is no longer valid when you click
the button.

It is better to evaluate $base immediately though, and for that you could
say
-command "$base.clientarea.browseinstalled configure -state disabled"
(In Tcl, braces are for quoting and quotes are for grouping. Don't ask.)

As Bryan says, in the odd case that $base could contain a space, that
would break your command. In order to ensure that each "word" of the
original code becones one "word" for the -command, you can let the
list command do the quoting:
-command [list $base.clientarea.browseinstalled configure -state disabled]

Now we are back to [ ] which execute a command immediately, but the command
that gets executed is "list", which takes each of its arguments and applies
appropriate quoting to ensure they remain items of a list.

For example

set base "foo bar"
list $base.clientarea.browseinstalled configure -state disabled

gives

{foo bar.clientarea.browseinstalled} configure -state disabled


$::base.clientarea.browseinstalled configure -state normal
Nothing wrong there, unless this whole block is situated inside
a namespace, in which case the base variable is not the global
var ::base but some_namespace::base.

If you can insert "debugging" messages, try inserting

puts "Scope nesting level: [info level]"
puts "Current namespace: [namespace current]"

at that point, which will tell you if the code is being executed in some
localized context -- either a proc body or a namespace.



--
Donald Arseneau asnd@xxxxxxxxx
.