Stuart Overton <[EMAIL PROTECTED]> writes:

> ...(with-events ()  (:quit-event () t)  (:mouse-motion-event  (:x x :y 
y)      (when (<= y 20)  ; If the cursor is within the top 20 rows of pixels, 
drop down a menu          ... ; Drop down a menu 100 pixels high.
>           (with-events ()              (:quit-event () t)              
(:mouse-motion-event (:x x :y y)
>                   (when (> y 100) ; If the cursor leaves the top 100 rows of 
pixels, close the menu                        ... ; Close the 
menu                        (push-quit-event)))))))


Under the covers, PUSH-QUIT-EVENT inserts a SDL_quit event into the SDL queue 
for the reasons Justin explained. However the SDL_quit event should be removed 
from the event queue, just as any other keypress is removed from the queue.

I'm just guessing, but there may be situations where more than one SDL_quit 
event is added to the queue. This would explain why sometimes the application 
breaks out of both nested with-event loops.

On the topic of nesting with-event macros; as Justin stated, the with-events 
macro allows this. However I think the correct approach is to use a state 
machine for managing this kind of UI behaviour.

This evening I will commit a change to empty the SDL event queue of pending 
events after a SDL_quit event is received, prior to exit. The previous 
behaviour was to end the event queue as soon as the SDL_quit event was 
processed (leaving events in the event queue). This should remove the need for 
messy hacks. However this means that if an SDL_quit event is followed by e.g. a 
keypress event, the inner with-events loop will swallow both events before 
returning control to the outer with-events loop.

- Luke

_______________________________________________
application-builder mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/application-builder

Reply via email to