Hi Christophe,
This is a very interesting bug.
What do you mean when you say "screen" ? Do you mean "window" ?
I expect that it is just a window face which contains the nine
image faces.
I would love to see the code, or at least know the arrarngement of
the face hierarchy structure, to try to reproduce the bug.
For clearing the event queue, I advise to look into WAKE-EVENT:
>> print mold get in system/view 'wake-event
func [port /local event no-btn][
event: pick port 1
if none? event [
if debug [print "Event port awoke, but no event was present."]
return false
]
either pop-face [
if in pop-face/feel 'pop-detect [event: pop-face/feel/pop-detect
pop-face event]
do event
found? all [
pop-face <> pick pop-list length? pop-list
(pop-face: pick pop-list length? pop-list true)
]
] [
do event
empty? screen-face/pane
]
]
Maybe you could modify it like so:
clear-event-port?: yes
wake-event: func [port /local event no-btn][
either clear-event-port? [
while [event: pick port 1]
clear-event-port?: no
][
event: pick port 1
]
...
]
Anton.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Coussement Christophe
> Sent: Friday, 20 January 2006 8:19 pm
> To: [EMAIL PROTECTED]
> Subject: [REBOL] Re: Request info about "Crash (Should not happened)"
> error
>
>
>
> Thank to all for the given information.
> After a lot of research and thinking, we could find the conditions which
> causes the crash.
>
> Our system is a "Computer Based Assessment" system, which allows us to
> submit persons to psychotechnical tests. One of those test is composed
> of a screen displaying 9 images, which stays visible during 5 sec. The
> person must choose one of those images by clicking it. After the delay,
> the screen desippear and a new screen is displayed.
> We noticed that, when a person clicks outside the image-button and hold
> the mouse button depressed, and the limit of 5 sec is reach, the other
> screen is constituted and the application crashes.
>
> Our conclusion is:=20
>
> Holding the mouse button creates an event which is queued for handling.
> When the new screen is composed, a 'feel+engage event is triggered, for
> the chronometer. When rebol starts this event, some mouse-event
> remaining from the previous screen was not completely handled and causes
> the crash.
>
> What we think to do:
>
> Before the new screen is composed and displayed, first "flush" the event
> queue for cleaning the old mouse event that remains.
>
> Does it make sense ? And how could we achieve this ? I am not aware of a
> clear-events instruction, and a 'do-events just brake the system.
>
> TIA,
>
> --christophe
--
To unsubscribe from the list, just send an email to
lists at rebol.com with unsubscribe as the subject.
