Yes, good point. Their wording in the help text is a little misleading, but I assumed from the start (way back) that the cleanup code for a form (QueryUnload, Destroy, etc.) would obviously run prior to dropping out of the Read Events and moving on to whatever's after that. My problem was that my code was a little complex for this app and simplifying and centralizing it fixed the problem. Plus, this was a situation where it behaved just a bit differently in the IDE vs. when it ran live. It *looked* fine in the IDE but really wasn't. Only when running the EXE straight from Windows did the problem show up (and then only in certain situations).

>Another way to look at this issue: Clear events forces the code after "read events" to execute!
>
>>Ok - got that solved. I realized that my code to close the form (and therefore the app) was a bit complex. It was based on some assumptions from my regular apps, but this one is more simplistic, so I really had some code that didn't need to be there. I was able to remove some code and centralize everything into the Destroy event of the form and now it's working like a champ . . .
>>
>>>I have an app that runs as a top-level form. So when the user exits the form, he's exiting the entire program. I discovered a situation where the program was not closing properly (though it appeared to). The help text regarding CLEAR EVENTS indicates that when that statement is executed, code execution picks up immediately after the READ EVENTS statement. Well, that doesn't actually seem to be the case, but it's not an issue in my "regular apps" - they shut down properly. With this app I experience a problem. Although I could skip a "Close" or "Exit" button and just make the user click the Close button at the upper right of the window's title bar, I did put an Exit button to just make things a little clearer. So the Exit button calls an exit procedure that does this:
>>>
>>>

>>>release oForm  && Global reference to the form itself
>>>clear events
>>>thisform.release
>>>

>>>
>>>This is actually a bit different than my previous code, which worked in most situations, but failed in a particular one. So now I've "improved" it by making it fail all the time. But the point is that I'm not getting the program to shutdown like it should. As I mentioned, it appears to shutdown, but the EXE is still in use. If I try to rename it, I can't until I issue a CLOSE ALL, CLEAR ALL. Tracing the shutdown code seems to result in behavior that is a bit different, making it harder to determine what's really going on.
>>>
>>>Thanks,
>>>
>>>Russell Campbell