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)