Hi, Thanks for the explanation. It makes sense now. Before it was just odd.
I was planning to reuse slider% to make a slider that will snap to a set of discrete values (not necessarily with a fixed distance between them). Would the simplest implementation strategy be to implement it from scratch (using a canvas to draw the line and handle) rather than reuse slider% ? /Jens Axel 2012/4/2 Matthew Flatt <[email protected]>: > Sorry for the delay! I see that the same question went unanswered in > 2011, too, although the answer is available from September 2009: > > http://lists.racket-lang.org/users/archive/2009-September/035316.html > > That old message's prediction that a new `racket/gui' (formerly MrEd) > would solve the problem turned out to be overly optimistic. The > mismatch between eventspaces and GUI toolkits turns out to be deep > enough that the completely reimplemented `racket/gui' is only a little > better than the old implementation. > > > To recap, the problem is that the underlying GUI toolkit (Cocoa, Gtk, > or Win32) takes control when the slider is clicked, and the toolkit > does not return control until the slider is released. The `racket/gui' > library's handling of callbacks is obligated to stay within the same > Racket thread as when the slider was initially clicked, because nested > toolkit calls may depend on the enclosing dynamic context for various > reasons. Consequently, if a slider callback (or some indirect callback, > such as `on-subwindow-event') synchronizes in such a way that other > Racket thread must first proceed, then the continuation of the callback > is delayed by `racket/gui', and control is returned immediately to the > underlying toolkit. When the toolkit relinquishes control after > handling the click, any delayed callbacks can be completed. > > In the case of printing output that will appear in DrRacket, > synchronization is required with DrRacket's GUI thread. That's why > printing makes your example get stuck. > > > (A reader who hasn't heard of this problem may now be tempted to > suggest a workaround that involves multiple OS level threads, or > something like that. All I can say is that I haven't been able to make > anything like that work, despite two serious attempts.) > > > At Mon, 2 Apr 2012 22:37:11 +0200, Jens Axel Søgaard wrote: >> The following program shows a slider. >> Why does the slider stop working, when I uncomment the display line? >> >> #lang racket >> (require racket/gui) >> >> (define integer-slider% >> (class* slider% () >> (super-new) >> (inherit get-value) >> (define down? #f) >> (define/override (on-subwindow-event receiver event) >> (begin0 >> (super on-subwindow-event receiver event) >> ; (display (get-value)) (display " ") >> )))) >> >> (define frame (new frame% [label "Example: How to use real-slider%"])) >> (define real-slider >> (new integer-slider% >> [parent frame] [label "x:"] >> [min-value 1] [max-value 100] [init-value 50])) >> >> (send frame show #t) >> >> >> -- >> Jens Axel Søgaard >> >> ____________________ >> Racket Users list: >> http://lists.racket-lang.org/users -- -- Jens Axel Søgaard ____________________ Racket Users list: http://lists.racket-lang.org/users
