At Fri, 2 Dec 2011 03:35:24 +0000, "Jeff C. Britton" wrote: > If I hold onto a corner and keep dragging it, eventually it appears that an > event is missed and then the window can be resized without painting taking > place. You need to keep dragging the corner for 30 seconds to a couple of > minutes.
That behavior is the result of a compromise between the Windows model of events/threads and the Racket model of eventspaces. As you are resizing the Window, the Win32 toolbox runs a modal event loop. During that kind of loop, evaluation at the Racket level is constrained; a Racket thread switch is not allowed, because the thread switch would change the C stack and confuse Win32 during any call back to Win32 function. Racket's GUI library therefore goes into a kind of best-effort mode during modal-event callbacks. It runs the usual event callbacks, but only for events whose destination is the same eventspace as the original modal-triggering action, and only if they complete quickly enough. For many purposes, this best-effort handling works well, and many callbacks succeed to refresh, say, the DrRacket window as you resize it or scroll around in an editor. If a callback ever misses the deadline, however, then evaluation of all callbacks are suspended until the modal loop is done. Problematic modal loops are ultimately always under the control of an end-user. For example, a bad program in a different eventspace cannot keep DrRacket's refresh from happening, but a user who continues to resize the DrRacket window can delay the refresh indefinitely. > Is it possible for the user to handle the window size event? To be clear, all of the usual callbacks happen during a resize (for the eventspace of the window that is being resized), but only as long as they complete fast enough and don't try to synchronize with other threads. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
