[futurebasic] Re: Break ... Until

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : December 1997 : Group Archive : Group : All Groups

From: Rick Brown <rbrown@...>
Date: Sat, 27 Dec 1997 11:02:04 +0000
I wrote:
> >Now FN beeper executes a loop and keeps beeping like crazy.  You sit
> >there hammering away at Command-period, and this causes Command-period
> >events to stack up in the queue.  But since no HANDLEEVENTS is being
> >executed, the queue never gets read, FB doesn't know it's supposed to
> >jump to FN handleBreak, x never gets set to 1, and the beeping
> >continues.

Peter replied:
> Sounds like a job for BETTER HANDLEEVNTS! (Hope FB3 does it)

If I understand right, it sounds like your suggestion for an improvement
would be to have FB react to events (or at least Command-period events)
as soon as the event happens.  I don't think that would be an
improvement, for a couple of reasons:

1. It would slow down execution tremendously.  FB would essentially have
to (internally) check the event queue after each statement executed.

2. It would cause jumps to event handlers from unpredictable locations
in the code.  I had a hell of a time with QuickBasic (which uses this
event model) for that reason.  The user might click a button while the
code was in the middle of a FOR loop, and the program would jump
directly to an event handler, even though I _really_ wanted to make sure
the FOR loop finished _before_ the jump occurred.  With HANDLEEVENTS,
you get to control the flow of your code.

> Must be a case of a global variable is a global variable _unless_ its
> locked away inside a loop. Pity, would make things easier.

No, your "x" and "programEnds" are still global--they just never get set
to 1, because FN handleBreak never gets executed, because the event
queue never gets read (after you enter FN beeper), because you never
call HANDLEEVENTS after you enter that function.

- Rick