Re: callbacks with <Button>s
> Hello all. I'm trying to use the various Tk-classes that come with
> STk and am running into some trouble. Take the following as an example.
>
> When I try this expression:
>
> (let ((b (make <Button>)))
> (set! (command b) `(describe ,b))
> (pack b))
>
> I get the following message when I click on the newly created button:
>
> *** Read from string error:
> bad # syntax: "#"
>
It is "normal". When calling a Tk function, the interpreter try to produce a
string representation of all the parameters:
- strings are left as is
- numbers are "printed" in decimal
- Tk commands (#[Tk-command ...]) are represented by their name
- ... (see appendix A of the reference manual for others)
For other types, the value passed to Tk is the string you obtain when you use
the "write" procedure. Instances objects are in this case. So when you pass
an instance, which can be an object built on Tk or NOT, the value passed is
something like #[<button> 1891b8].
> However, a slight modification corrects the problem:
>
> (let ((b (make <Button>)))
> (set! (command b) `(describe (Id->instance ,(Id b))))
> (pack b))
>
> What strikes me as odd is that the result of Id has roughly the same
> syntax as the object itself (#[<button> 1016f110] versus #[Tk-command
> .v1]), yet one has "bad # syntax" and the other doesn't.
>
To be more concise, Tk-command are known by the interpreter when calling a
Tk fucntion. For object, it is a little bit more complicated since
objects are not always derived of the <Tk-object> class.
A simpler way to program the preceding construct coul be
(let ((b (make <Button>)))
(set! (command b) `(describe ,(address-of b)))
(pack b))
> I was expecting the first expression to work (should I have?), so
> is this a bug?
I think it is not a bug, but it is not a desirable situation.
A better solution would be that the interpreter use a function to pass
the string representation of an object. Of course this function could be
written in Scheme. We can imagine something like
(define-method stringify-for-Tk ((self <Tk-object>))
address-of self))
(define-method stringify-for-Tk (self)
self)
With this, if the interpreter has a <Tk-object> direct or indirect instance to
pass to Tk it will pass its address. In other cases, we fall in the current
situation.
Advantage: Script using address-of will always work
Disadvantage: Extensions written in C will have to use probably a slightly
different protocol (need of one more pointer to the print-for-tk-function).
What are the mailing list users things about that?
-- Erick
Received on Tue Jul 19 1994 - 13:28:33 CEST
This archive was generated by hypermail 2.3.0
: Mon Jul 21 2014 - 19:38:59 CEST