Nick,

I know we all call it a "wait state" (what read events results in), but I must admit that when I read that "explanation" I found myself wondering why they didn't call it "Wait Events" since what it really does ia let us "wait" for a user to *do* something (causing an event).

My *guess* would be that "wait state" is the "easy out" for an explanation, and that more likely something much more fundamental is actually going on. Something along the lines of giving WIN "control" on our behalf, at the same time identifying our app as the "owner" of specific rel-estate on the screen.

Not diagreeing with you, just adding commentary.
Cheers
Jim N

>>could someone point me to a good explanation of the read events / clear events cycle?
>>i've been doing pretty good with it, but really just getting things to work and not quite understanding why they work that way.
>>
>
>You need READ EVENTS in your app to create a wait state and process events in the app. The form itself may be run from Form Designer without READ EVENTS, but if you run app and there is no READ EVENTS it will just flash and end.
>You issue CLEAR EVENTS somewhere in app when you would like to terminate the app, so there will be code executed (if any) starting the next line after READ EVENTS (usually some closing procedures)
>
>HTH,
>Nick