[ltk-user] getting an item's ID

[Peter Herth]

Hi Kenny,

great to see you onboard :)

On 2/1/06, Kenny Tilton <ktilton at nyc.rr.com> wrote:
> I am merging my Cells fork of LTk with LTk, by which I mean using as
> much as possible LTk low-level stuff along with my own DEF-C-WIDGET
> high-level stuff. Things look OK so far, but I had a problem using
> ltk::read-data to get back the item ID no after creating an item.

Thomas just talked me into doing something similiar - so if I can
help, I will gladly do so :)
As a general remark: if you have not got Ltk 0.88 yet, get it today!

> My problem is that the ID no comes back as an unvarnished "42". But
> read-data is looking for (:data <data>):
>
> (defun read-data ()
>   (let ((d (read-wish)))
>     (if (listp d) ; paranoia check when we do not read a list eg. error
> messages from wish
>     (progn
>       (loop while (not (equal (first d) :data))
>         do
>         (setf *event-queue* (append *event-queue* (list d)))
>         (setf d (read-wish)))
>       (second d))
>       (format t "read-data:~a~a~%" d (read-all *wish*)))))

Well, all the item creation functions do send the answer tagged. As I
want to send data always and ever only tagged, I have created the
senddata functions on the tk side (senddata, senddatastring,
senddatastrings) which take care of tagging, and in the case of
strings, properly escaping the characters in the strings to be
lisp-readable.

> How do I arrange for Tk to respond with (:data 42) when I create an
> item? Or does read-data need to handle un-tagged data from Tk differently?

(defun create-line (canvas coords)
  (format-wish "senddata [~a create line~{ ~a~}]" (widget-path canvas) coords)
  (read-data))

That should be the template for any of those functions.

>
> Aside: I just noticed:
>
> (defun read-event (&key (blocking t))
>   (or (pop *event-queue*)
>       (when (or blocking (can-read *wish*))
>         (read-preserving-whitespace *wish* nil nil))))
>
> Should that be checking to see if any data read from Tk is tagged
> (:callback ,,,,)?

read-event just reads, the tag-checking is done in process-one-event.
The different event types differ on the lisp side only in the
signature of the called function - command callbacks receive either
zero or one arguments, the one argument is then the new value of the
widget, generic events created by bind pass an event structure to the
callback function, containg e.g. the mouse coordinates or key codes.

Peter