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)
____________________
Racket Users list:
http://lists.racket-lang.org/users
