I have this problem of my program. The program runs well but the moment I am going to quit/exit from the program, the exe file is still running in the computer task manager? It will only exit in the task manager when I click the end task. Does anybody knows how to exit in the task manager using a command in VFP program so that I can embed it in the form or prg?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How to exit from the computer task manager?
- Thread starter lencui
- Start date
Olaf Doschke
Programmer
See faq184-6512, if you want to do a single form application without a menu.
In a normal multi-document (multi-form) application the typical program flow of a VFP EXE in main.prg is:
Settings and Preparations, probably including to create a menu in _SCREEN and afterwards or instead start a main form.
READ EVENTS
cleanup code - if at all
And to end: CLEAR EVENTS
This has one prerequisite: Your main form is non-modal. If it is, the READ EVENTS only becomes active after you close the main form. And that could be a situation you have, your EXE will go into its normal idle mode after you close it, and the form is gone, nothing is visible, but the EXE stays in the task manager.
The typical error novices rather face is having a normal non-modal form and no READ EVENTS, then the opposite of your situation happens, the EXE starts and vanishes right away, your main form does not stay and the EXE process merely appears in the task manager and vanishes. The two possible solutions now are to a) make the main form modal or b) add a line READ EVENTS in main.prg after starting the main form. But don't do both. If you do both, you don't have double safety, you have an EXE showing the unwanted behavior to stay active.
The main thing to do is not CLEAR EVENTS, though, but QUIT to ensure you exit from endless loops or other blocking code, too. If you have a main form CLEAR EVENTS is well put into its Unload event, but the menu item to exit should do QUIT. QUIT does not - as often thought of and as the help topic suggests - exit immediately, it just causes every object to destroy and every form to release and in regard to forms that triggers all forms QueryUnload events. You don't need to do anything there, but look up the help topic on QueryUnload to see what you could do there. In regard to any class instance, look up what you can do in Destroy. Since all forms unload, the main form having CLEAR EVENTS in its Unload makes QUIT cause the CLEAR EVENTS, too. Closing the main form then causes CLEAR EVENTs to happen without first QUIT. Don't worry this means all objects will not be released in that scenario, the QUIT behaviour also occurs when you reach the end of code after READ EVENTS, I just recommend starting off with QUIT and not CLEAR EVENTS, as a MessageBox or even a report preview may hinder CLEAR EVENTS to really do its job and QUIT is the better start. If you can close the main form, no such modal thing hinders CLEAR EVENTS to work, but it also does not hurt to put QUIT after READ EVENTS, so it happens in both situations you close the main form or exit via the exit menu item.
The real ending just occurs, when there is no further code to execute and nothing else on the call stack keeping VFPs program execution alive. As said the help topic about QUIT is misleading, QUIT causes everything to release, also a global goApp variable, so also Destroy Events of classes happen before Quit really exits the process. If you have a cleanup code, it belongs into each separate class and form definition, not a general code after READ EVENTS. Also notice VFP not only has a loader part of its EXE starting up the VFP runtime and its code interpreter maintaining the call stack and program pointer, it also cleans up after itself on its own, closing all workareas, ending all data sessions, clearing all memory usage and more, so you don't need to care about all these things. Just like at runtime releasing a form also clears and removes that forms private datasession, the datasession 1 you already have before any form or object right at main.prg also is automatically cleared by the VFP runtime closing.
Bye, Olaf.
In a normal multi-document (multi-form) application the typical program flow of a VFP EXE in main.prg is:
Settings and Preparations, probably including to create a menu in _SCREEN and afterwards or instead start a main form.
READ EVENTS
cleanup code - if at all
And to end: CLEAR EVENTS
This has one prerequisite: Your main form is non-modal. If it is, the READ EVENTS only becomes active after you close the main form. And that could be a situation you have, your EXE will go into its normal idle mode after you close it, and the form is gone, nothing is visible, but the EXE stays in the task manager.
The typical error novices rather face is having a normal non-modal form and no READ EVENTS, then the opposite of your situation happens, the EXE starts and vanishes right away, your main form does not stay and the EXE process merely appears in the task manager and vanishes. The two possible solutions now are to a) make the main form modal or b) add a line READ EVENTS in main.prg after starting the main form. But don't do both. If you do both, you don't have double safety, you have an EXE showing the unwanted behavior to stay active.
The main thing to do is not CLEAR EVENTS, though, but QUIT to ensure you exit from endless loops or other blocking code, too. If you have a main form CLEAR EVENTS is well put into its Unload event, but the menu item to exit should do QUIT. QUIT does not - as often thought of and as the help topic suggests - exit immediately, it just causes every object to destroy and every form to release and in regard to forms that triggers all forms QueryUnload events. You don't need to do anything there, but look up the help topic on QueryUnload to see what you could do there. In regard to any class instance, look up what you can do in Destroy. Since all forms unload, the main form having CLEAR EVENTS in its Unload makes QUIT cause the CLEAR EVENTS, too. Closing the main form then causes CLEAR EVENTs to happen without first QUIT. Don't worry this means all objects will not be released in that scenario, the QUIT behaviour also occurs when you reach the end of code after READ EVENTS, I just recommend starting off with QUIT and not CLEAR EVENTS, as a MessageBox or even a report preview may hinder CLEAR EVENTS to really do its job and QUIT is the better start. If you can close the main form, no such modal thing hinders CLEAR EVENTS to work, but it also does not hurt to put QUIT after READ EVENTS, so it happens in both situations you close the main form or exit via the exit menu item.
The real ending just occurs, when there is no further code to execute and nothing else on the call stack keeping VFPs program execution alive. As said the help topic about QUIT is misleading, QUIT causes everything to release, also a global goApp variable, so also Destroy Events of classes happen before Quit really exits the process. If you have a cleanup code, it belongs into each separate class and form definition, not a general code after READ EVENTS. Also notice VFP not only has a loader part of its EXE starting up the VFP runtime and its code interpreter maintaining the call stack and program pointer, it also cleans up after itself on its own, closing all workareas, ending all data sessions, clearing all memory usage and more, so you don't need to care about all these things. Just like at runtime releasing a form also clears and removes that forms private datasession, the datasession 1 you already have before any form or object right at main.prg also is automatically cleared by the VFP runtime closing.
Bye, Olaf.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
