[racket] Queuing calls to printf

Hi all,

In the GUI, if the call-chain of on-subwindow-event method calls does not
complete without requiring another thread to run, the mouse-event% will not
get delivered to the target. And then the target widget of the mouse-event%
will not operate the way it should, e.g. a slider% will not slide, a
list-box% will not select, etc..

Since printf requires another thread to run, adding calls to printf in
on-subwindow-event, or anything on-subwindow-event calls directly, will
cause a GUI to break.

I find printf's invaluable for sanity checks during debugging and so have
developed a little wrapper around printf based on a conditional printf
trick I saw in the MrEd Designer source. Basically the idea is to put the
printf in a thunk that will be executed at a later time, maybe by another
thread, and allow the caller (e.g. on-subwindow-event) to complete without
requiring another thread.

My questions are these: Is this a safe and practicable approach to use? Am
I reinventing something that already exists? Does this need to be
generalized in some way to use a different eventspace or something?

Cheers,

Kieron

****

#lang racket/base

(require racket/gui)

(define (queued-printf . msg)
  (let {[print-msg msg]}
    (queue-callback
     (lambda () (apply printf print-msg))
     #t)))

(define f
  (new
    (class frame%
      (super-new)
      (define/override (on-subwindow-event r e)
;        (printf "on-subwindow-event: ~a ~a ~n" r (send e get-event-type))
; un-comment to "break" the GUI
        (queued-printf "on-subwindow-event: ~a ~a ~n" r (send e
get-event-type))
        #f))
    [label "test queued-printf"]
    [min-width 400]
    [min-height 200]
    ))

(define lb
  (new list-box%
    [parent f]
    [label "list-box%"]
    [choices (list "alpha" "bravo" "charlie")]
    ))

(send f show #t)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121008/1e559752/attachment.html>