[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Redraw continuously

Many of the view generic-functions (e.g. set-view-size,
set-view-container (called by add-subviews & remove-subviews),
set-view-position, set-dialog-item-text) do not redraw. They schedule a
redraw by calling invalidate-view or invalidate-corners. Then all the
redrawing happens at once the next time event-dispatch runs (very often
while the Listener is idle, 3 times a second (*foreground-event-ticks*)
otherwise). If you need for updating to happen earlier, you need to do
something. The easiest is to call EVENT-DISPATCH with no arguments. You
can also call WINDOW-UPDATE-EVENT-HANDLER on windows that you know need
to be updated. If you're willing to think hard or know that your views
can't overlap, you can also call VIEW-FOCUS-AND-DRAW-CONTENTS on views
that you know need to be redrawn (probably coupled with calls to
VALIDATE-VIEW so that the drawing won't happen a second time when

Thus, your examples become:

(dotimes (i 20)
  (set-view-position <view> (make-point <new point>))
  (delay one second) )

(remove-subviews <view> <subviews>)
(move-to <view> <position>)
(line <view> (another position>)

There is one complication here. If, as in the VIEW-EXAMPLE.LISP file in
the examples folder, the SET-VIEW-POSITION is done by an event handler
(e.g. VIEW-CLICK-EVENT-HANDLER), then EVENT-DISPATCH will do nothing
(EVENT-DISPATCH doesn't allow itself to be reentered). In this case,
calling WINDOW-UPDATE-EVENT-HANDLER is the best idea, and that is what
the VIEW-EXAMPLE code does in order to update its display during
subview dragging. One warning: do not reenter
WINDOW-UPDATE-EVENT-HANDLER or your window's visrgn is likely to get
messed up and you'll be very confused (I haven't ever done this so I
don't know exactly what happens. I only know that the ROM is likely to
do something weird if one calls #_BeginUpdate twice before calling
#_EndUpdate twice). Thus, it is a BAD IDEA to call