Thank to you all for reading me and giving advices. I could found some
element which helped with the hunting-the-bug process.
Actually, the solution was rather simple when I found the problem.
In short:
Fact 1:
- we have a window which appears for 5 sec. This time is computed into a
fell+engage event.
- after the 5 sec, we had to reset the "chronometer". This was done by
setting the rate to 'none:
ubox_chrono/rate: none
Fact 2:
- earlier, we found out that our application was too memory consuming,
which was a problem on old PC. After 250 windows generation, we used
some 60 MB RAM, which was not released by the GC.=20
- to prevent this, after each window hiding, we reset all the composants
of it by:
=09
foreach elem upnl_workzone/pane/pane [=20
foreach facet remove first elem [set in elem facet none]
]
- this gave us a memory use of only 2MB after 430 windows generation...
Observation:
- with this approach, the rate was set twice to 'none
- this was the only inconsistency noticed into the code
Solution:
- removing the line "ubox_chrono/rate: none" resolved the described
instability problem.
Now, the application has been used a 1000 time since Monday, by some 800
different people, on 3 different OS, on 10 different configurations and
about 5 different hardware's, without any problem.
REBOL RULES :-)
--christophe
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Anton Rolls
> Sent: Friday 20 January 2006 18:10
> To: [EMAIL PROTECTED]
> Subject: [REBOL] Re: Request info about "Crash (Should not=20
> happened)" error
>=20
>=20
>=20
> Hi Christophe,
>=20
> 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=20
> nine image faces.
> I would love to see the code, or at least know the=20
> arrarngement of the face hierarchy structure, to try to=20
> reproduce the bug.
>=20
> For clearing the event queue, I advise to look into WAKE-EVENT:
>=20
> >> 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:=20
> 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
> ]
> ]
>=20
> Maybe you could modify it like so:
>=20
> clear-event-port?: yes
>=20
> 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
> ]
> ...
> ]
>=20
> Anton.
>=20
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf=20
> > Of Coussement Christophe
> > Sent: Friday, 20 January 2006 8:19 pm
> > To: [EMAIL PROTECTED]
> > Subject: [REBOL] Re: Request info about "Crash (Should not=20
> happened)"
> > error
> >
> >
> >
> > Thank to all for the given information.
> > After a lot of research and thinking, we could find the conditions=20
> > which causes the crash.
> >
> > Our system is a "Computer Based Assessment" system, which=20
> allows us to=20
> > submit persons to psychotechnical tests. One of those test=20
> is composed=20
> > of a screen displaying 9 images, which stays visible during=20
> 5 sec. The=20
> > person must choose one of those images by clicking it. After the=20
> > delay, the screen desippear and a new screen is displayed.
> > We noticed that, when a person clicks outside the image-button and=20
> > hold the mouse button depressed, and the limit of 5 sec is=20
> reach, the=20
> > other screen is constituted and the application crashes.
> >
> > Our conclusion is:=3D20
> >
> > Holding the mouse button creates an event which is queued=20
> for handling.
> > When the new screen is composed, a 'feel+engage event is triggered,=20
> > for the chronometer. When rebol starts this event, some mouse-event=20
> > remaining from the previous screen was not completely handled and=20
> > causes the crash.
> >
> > What we think to do:
> >
> > Before the new screen is composed and displayed, first "flush" the=20
> > event queue for cleaning the old mouse event that remains.
> >
> > Does it make sense ? And how could we achieve this ? I am=20
> not aware of=20
> > a clear-events instruction, and a 'do-events just brake the system.
> >
> > TIA,
> >
> > --christophe
>=20
> --
> To unsubscribe from the list, just send an email to lists at=20
> rebol.com with unsubscribe as the subject.
>=20
>=20
>=20
> **************************************************************
> *******************
> Your E-mail has been scanned against Potential Virus and=20
> Spyware/Grayware dangers by the MOD BE SECURITY SYSTEMS.
>=20
This e-mail and any attachments may contain confidential and
privileged information. If you are not the intended
recipient,
please notify the sender immediately by return e-mail,
delete
this
e-mail and destroy any copies. Any dissemination or use of
this
information by a person other than the intended recipient is
unauthorized and may be illegal.
--
To unsubscribe from the list, just send an email to
lists at rebol.com with unsubscribe as the subject.
