Ok, that makes sense, I think. So READ EVENTS doesn't really have an effect on form & coding that has user interaction? You can run forms, display data, fire WAIT WINDOWS, etc WITHOUT a READ EVENTS? So therefore, READ EVENTS is sort of like a transaction processor... start here (READ EVENTS), store stuff until the end (CLEAR EVENTS) and committ those changes?!? - now wait, that doesn't sound right... maybe I should just leave it alone the way it was and not try to understand it... cept I'd like to...

Am I Close?


p.s. In my case, MYSYSTFORM "is" a modal form and it is before the READ EVENTS, so how is that affected?



>>do form mbappform
>>read events
>>
>>
>>Should the READ EVENTS be the last item? I guess I don't understand fully
>>what READ EVENTS does. I know it starts "event processing" which I believe
>>is the "processing" of commands, buttons, code, etc.
>
>What it does is stop the flow of the program it's in. When you run your form, the initialization code will run, and then the form will just sit there until it is released or the application ends. If the form is not modal, and if there's nothing to stop the application from ending, the form will disappear immediately.
>
>However, if you have a READ EVENTS, the application waits on that command, letting you choose menu items, form controls, etc., until there is a CLEAR EVENTS, which lets the application continue past the READ EVENTS. If you have code before the READ EVENTS, it will execute before you get there, and a CLEAR EVENTS will have no effect, since you aren't in the READ state yet.
>
>Does this make sense?