At Mon, 8 Oct 2012 13:58:00 -0600, Kieron Hardy wrote: > 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.
Right. > 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? Another option is logging via `log-debug'. ____________________ Racket Users list: http://lists.racket-lang.org/users
