I use a single READ EVENTS "loop" in my apps, which loops until "Quit = .T."., and contains a READ EVENTS at the "top" of the loop.

Any "key" events are handled by a CASE within this loop; after the READ EVENTS statement.

Any "major event" that needs attention and that can't be handled (safely) on the fly, stores event details that are handled in the CASE, and then issues a CLEAR EVENTS. Consequently, any "remaining code" is always executed before control falls "out" of the READ EVENTS into the CASE.

This loop will continuing "looping" without issuing another READ EVENTS as long as there are "pending" events (some events can generate other "events" on a stack). Once all the outstanding events are handled, the READ EVENTS is (re)executed and the system goes back into its regular waiting state.

>I currently employ the second in a process monitor. There are other events firing and things were getting knocked of course by my process polling in the timer.
>
>The reason I asked the question was because of something I read somewhere about 'block mode' processing whereby timer events (or other events) only get a looking after all the code in a method or event has completed. I have never been able to find it since and am now wondering whether it was in Foxpro at all. Ho hum!!!