Is your form Modal (WindowType=1) ? If it is, your READ EVENTS is redundant and what's happening is that your CLEAR EVENTS in the QueryUnload isn't clearing anything, because your READ EVENTS hasn't occured yet.


>hi gerry,
>
>i'm so sorry to bother you.. but i haven't really have my EXE working =(
>
>in my DTR form, i put READ EVENTS after DO FORM log, below is the complete code:
>
>INIT EVENT
>
>PUBLIC lOclicked
>lOclicked=.F.
>
>LOCAL lcResourceTo, lcResourceOnOff
>lcResourceOnOff = SET('RESOURCE')
>lcResourceTo = SET('RESOURCE',1)
>SET Resource TO PrntUser
>
>Application.Visible=.F.
>_Screen.Visible=.F.
>DO mainmenu.mpr WITH THIS, .T.
>
>DO FORM log TO lOclicked
>READ EVENTS
>
>
>in FORM LOG's queryunload,
>
>i have CLEAR EVENTS.
>
>
>now after form DTR is activated, i can't exit the form now. it doesn't show any error thought, it just do nothing. =(
>
>can you help me here?
>
>
>
>> I'm assuming you're only showing us "some" of your code, Evelyn.
>
>> At the same time, if you expect to have at least one Form "hang around" when running an EXE, you need a READ EVENTS in your main program.
>
>> Running from the command window is like running with an "implicit" READ EVENTS; that is another difference between an EXE and running from the command window.
>
>> "Windows" respond to events (like mouse and keyboard). READ EVENTS creates a wait state that allows these events to be handled. Without a READ EVENTS in your app, program flow simply runs from the beginning of your main program, "out the bottom".
>
>> Stop me if you've heard this before ... :)
>
>>>i'm also thinking that way.. so i tried removing the thisform.release in my active form..
>>>
>>>but it's still releasing my form..