>>>>In the Unload of the TL form, issue a CLEAR EVENTS. The form is being released but the application is still stuck on the READ EVENTS.
>>>
>>>I thought there was some reason not to do this in Unload (can't recall what, though). Historically, we have debated over whether Queryunload or Destroy was a more appropriate place (of course either works). I usually limit Unload to data-related code...it being the complement of Load.
>>
>>I suggested Unload as it is the last event fired as a form is released. I wasn't aware of any problems associated with this. I wouldn't put it in QueryUnload because that gets fired only when the user clicks on the X to close the form. If the form is Release(d) then it doesn't occur. The Destroy is perfectly acceptable (I'm saying that alot today < s >) to place the code.
>
>
>So the principle here is the READ EVENTS in my main.prg gets associated with the DO FORM MAIN screen and therefore the CLEAR EVENTS must be also associated ( read part of ) that form. When I put it in the MAIN.PRG the form was already closed and therefore nolonger in scope and couldn't close the events. Do I understand this correctly?
>Terry

Not quite. READ EVENTS is not associated with any form in particular. If you started a menu that you then could start up many different forms, none of these forms are "associated" with the READ EVENTS. You would then have a menu option that did a CLEAR EVENTS to get out of the internal loop.

It's only because you have a single form, with no menu, that you need the CLEAR EVENTS in the form.

In fact, you don't even need a READ EVENTS if your form was Modal, therefore you wouldn't need a CLEAR EVENTS, either.

HTH.