Yes, this is starting to make more sense...

>If your form isn't modal then you need a READ EVENTS after the form instatiation then on the release of the form you need the CLEAR EVENTS if you try to QUIT without you will receive an error saying cannot quit visual foxpro
>Also don't forget that modal forms cannot be TOP LEVEL form so you will not be able to put a menu or a toolbar on a modal form.
>Is this clear now?
>
>>So in my case, because the first form I am calling is MODAL, then READ EVENTS isn't needed at all? What if the MODAL form is not called (due to a subsequent run of the app and the data requirements being made)? Then I need a READ EVENTS after the MYINITIALFORM call? Finally is a CLEAR EVENTS required or does the QUIT in the ON SHUTDOWN cover that?
>>
>>>>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?
>>>>
>>>
>>>
>>>The READ EVENTS allows the form or the menu to actually be processed. So you need it (unless the form is modal).
>>>
>>>
>>>>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?
>>>>
>>>
>>>A READ EVENTS is not needed for a modal form. In the program (or form) that calls the modal form, processing will "wait" at the line that calls the modal form.