>>That's the easy part, but what if I'm in a routine which does some cleanup - and should behave differently if it's called while Read Events is on than when it's off? How would I know?
>>
>>One thing pops up (not a real lightbulb), I could maybe issue "Clear events", possibly followed by "Read events". Should Clear Events create any errors if it's issued when it shouldn't (like still having ten open forms), so at least the "run amok and catch the error" method can be used? I know I can try myself or look up the help, I actually want to know if someone tried it already and to what effect.
>
>Interesting idea. I've never done anything like this so I'm not sure of the consequences if any. After thinking through this more I have a question of my own. What circumstances are arising in your app that would cause a CLEAR EVENTS or READ EVENTS not being issued yet to occur without you being able to handle it in your code?

I'm just thinking over an old problem which is actually solved, but I still don't like the way I solved it.

I remember when I first started playing with VFP (3.0 beta), I had a modal form pop up before anything else, and it was CreateObject()ed; its .show method showed it, but it released because there was not any Read Events issued yet. The routine which ran this could have been called elsewhere in the app. I ended up issuing one extra Read Events (if there were no active windows already), but thought there was an easier way. It takes three extra lines of code as it stands now.