FB II Compiler
I think your code will have to _decide_ what events it wants to process. This sort of thing was discussed at great length in the "Break...Until" thread some time ago.
A sample code of what _I_ do is at the end of this email.
The main loop is:
This grabs the events in HANDLEEVENTS, leaps to an event "parser" (FN myHandleevents), which sets a global variable to indicate the state of that particular event. Then FN myHandleevents calls another function (FN processMyHandleevents) which looks at the global variables and decides what to do with them.
I do it this way because I want to see the event, but don't particulary want to get stuck inside HANDLEEVENTS. This may seem like double handling to some, but indirection is the name of my game. I use HANDLEEVENTS to detect the event, not to process the event.
Code example follows:
'This code waits for 2 sec then beeps continuously.
'Break and a mouse click are detected and end the program.
'Compile and run this program, otherwise you may become
'confused about what is actually happening. (The FB run
'environment continues to beep after you have done a
'break or a mouse click, the compiled code doesn't.)
COMPILE 0, _dimmedVarsOnly
LOCAL FN beeper
LOCAL FN processMyHandleevents
LOCAL FN myHandleevents
'Changes the value of a global variable based upon what
'HANDLEVENTS has found in the event queue.
LOCAL FN doBreak
LOCAL FN doTimer
LOCAL FN doMouse
ON BREAK FN doBreak
ON TIMER(2) FN doTimer
ON MOUSE FN doMouse