Tcl - Button with incremented number

Author

Button with incremented number

Michael Pachta

2005-06-01, 9:04 am

Hello,

for no special purpose (just curiosity as a TCL beginner) I created a
button that shows a number. With every click the number should be
incremented. My idea was this:

#! /usr/bin/wish
set i 1
button .b -text $i -command "incr i ; .b configure -text $i"
pack .b

But this doesn't work. Can anybody give me a hint?

Thanks,

Michael

Michael Pachta

2005-06-01, 9:04 am

Michael Pachta wrote:
> But this doesn't work. Can anybody give me a hint?

Sorry, forgot to write what doesn't work: the number gets incremented as
intended, but it won't get displayed as new button text. The initial "1"
remains.

Michael

tunity5@yahoo.com

2005-06-01, 9:04 am

Michael Pachta wrote:
> Hello,
>
> for no special purpose (just curiosity as a TCL beginner) I created a
> button that shows a number. With every click the number should be
> incremented. My idea was this:
>
> #! /usr/bin/wish
> set i 1
> button .b -text $i -command "incr i ; .b configure -text $i"
> pack .b

The button does change its label; it just happens to be to the same
value. I think you want to delay the computation of the label to run
time, when you click on the button. One way, with minimum change to
your code, is as follows:

% button .b -text $i -command "incr i ; eval .b configure -text \$\i"

In general, unless you have really simple calculations, the practice is
to call a proc. Then, in that proc, you could do your processing.

Andreas Leitgeb

2005-06-01, 9:04 am

Michael Pachta <mipani@gmx.de> wrote:
> #! /usr/bin/wish
> set i 1
> button .b -text $i -command "incr i ; .b configure -text $i"
> pack .b

In a double-quoted string, $i gets substituted immediately,
so the thing that you really end up passing to -command is:
"incr i ; .b configure -text 1"

In your case you could just easily write:
button .b -text $i -command {incr i ; .b configure -text $i}
or
button .b -text $i -command "incr i ; .b configure -text \$i"
(just protect that one $ from being processed too soon)
and it will work.

There's a much easier way, too:
button .b -textvariable i -command {incr i}
with -textvariable, the button will track the value of
the variable automatically. Don't forget to use just i,
(not $i) for -textvariable, because as its name implies, it
wants a variable, not a value.

Michael Pachta

2005-06-01, 4:01 pm

Andreas Leitgeb wrote:
> In a double-quoted string, $i gets substituted immediately,
> so the thing that you really end up passing to -command is:
> "incr i ; .b configure -text 1"
>
> In your case you could just easily write:
> button .b -text $i -command {incr i ; .b configure -text $i}

Thank you! That was really easy. Didn't know that the complete command
string gets processed (and all variable references will be substituted
at once when encountered by the interpreter). That's a bad trap.

> There's a much easier way, too:
> button .b -textvariable i -command {incr i}
> with -textvariable, the button will track the value of
> the variable automatically.

Will use this feature next time. Thanks a lot!

Michael

Bryan Oakley

2005-06-01, 4:01 pm

Michael Pachta wrote:
> Andreas Leitgeb wrote:
>
>
>
> Thank you! That was really easy. Didn't know that the complete command
> string gets processed (and all variable references will be substituted
> at once when encountered by the interpreter). That's a bad trap.
>

Not a bad trap; that's just the way the language is designed (and for
good reason, I'm sure you'll eventually discover). Substitution is
performed according to the rules on all arguments before giving them to
the commands for processing... and the rules say that things in "" get
substituted, things in {} don't.

Michael Pachta

2005-06-01, 4:01 pm

Bryan Oakley wrote:
[color=darkred]
> Not a bad trap; that's just the way the language is designed (and for
> good reason, I'm sure you'll eventually discover). Substitution is
> performed according to the rules on all arguments before giving them to
> the commands for processing... and the rules say that things in "" get
> substituted, things in {} don't.

The solution to my question was to use the curly brackets to prevent,
let's say, premature substitution (... -command {incr i ; .b configure
-text $i}). But substitution does happen. The button now shows 2,3,4
etc. and not the literal string $i. If I would write -text {$i} there
wouldn't be any substitution at all (as I would expect it).

But let's see what I learned:

1) "..." - immediate substitution of all variables
2) {...} - delayed subst. of variables
3) {...{$...}...} - no subst. of variables inside the inner braces

OK, I accept it and will consider it for later.

Thanks,

Michael

Andreas Leitgeb

2005-06-02, 9:03 am

Michael Pachta <mipani@gmx.de> wrote:
> But let's see what I learned:
> 1) "..." - immediate substitution of all variables
With "variables" you surely mean those with a $ in front.
same goes for command-substitution [blabla ...]

> 2) {...} - delayed subst. of variables
delayed? it depends on what you do with that thing.

If you later execute it some way (-command, eval, if, while, proc, ...)
then yes, it will be substed delayed. if you do not execute it
but perhaps only use it for -text, then it will be never substed.

All the rules about "will be substed" or "will not be .." are
always focused on the step of putting together the thing to
execute. What happens during execution is beyond the scope
of these rules.

e.g.
set var {puts $foo}
if 1 {puts $var}

In both cases, no substitution happens *during parsing the command*,
but the if conmmand then does another round on its second argument,
so you will see the value of $var , namely 'puts $foo' printed out.

> 3) {...{$...}...} - no subst. of variables inside the inner braces
eval { if 1 { puts $var } }

Sponsored Links