You can try:
ON SHUTDOWN EXECSCRIPT([on shutdown]+CHR(13)+[on error *]+CHR(13)+[clear events]+CHR(13)+[release all]+CHR(13)+[quit])
Main Topics
Browse All TopicsI know about issuing "ON SHUTDOWN CLEAR EVENTS" before "READ EVENTS" and I know about reissuing "ON SHUTDOWN" in your exit routine etc etc. And I've got a system which works exactly as I expect it to while I'm still in the VFP environment. I can deliberately cause an untrapped error and the program will shut itself down. However, as soon as I turn that into a standalone executable, the same error will produce the dreaded "cannot quit visual foxpro" and it's driving me mad!
The only clue I'm getting is that the refusal to quit seems to be tied up with native class Form Release code. (I've eliminated the possibility that it's my own code by only running that "if not quitting" (and the variable "quitting" exists))
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
pcelba: I don't quite see what you're aiming for. Your "script" woudl run (a subset of) what is already in my exit routine - which runs already.
jrbblda - that's a very interesting point. I hadn't considered the Modality of the forms. You're probably on the right track. The obvious question, however, is how the hell do I force them to close?
My exit routine already tries to close any open forms with a standard loop
FOR each oFrm in _SCREEN.Forms
oFrm.abandoned=.t.
quitting=.t.
oFrm.Release()
ENDFOR
(I use the two variables to make the forms skip code that I don't want to run if I'm quitting and, yes, I've tried it with and without them and different combinations)
I even thought of including "Thisform.windowtype=0" as a line in the class release code but that isn't permitted (gives an error "WINDOWTYPE IS READ ONLY" at run time.
So how else can we force a modal window to shut?
Don't worry. I've had this and other worries about a simple QUIT. But in fact it's "stronger" than CLEAR EVENTS and also gives you the chance to do more, as it does release all forms, you run through all the events, eg QueryUnload(). It still has problems with a Messagebox() though, IIRC, but there's little you can do about that.
Bye, Olaf.
Hi Tushar,
QUIT does also clear variables in the end, it also closes databases, connections. There are things holding a quit: Messagebox as said, and open transactions. Even ON ERROR * does not suppress the error message. Another reason to handle transactions correctly and as short as possible. You can DO WHILE TXNLEVEL()>0 ROLLBACK ENDDO before QUIT.
QUIT also does not quit immediately, it does cause forms to close and triggers QueryUnload()s. If you have good tidy up code in destroy events of classes and queryunload, unload and destroy of forms, then QUIT does it's job very well.
Cyril,
I don't see that a cleanup procedure can really do more than that. If you finally QUIT after first trying to do what QUIT also does, then you don't gain anything.
Remarks on QUIT in the help:
Always use QUIT to terminate a Visual FoxPro session. If you turn the computer off without issuing QUIT, open files might become damaged and data lost, and temporary work files that would normally be deleted may be left on disk.
One thing you can do additionally in a cleanup or exit procedure is Killprocess, that is, if you get to the line after QUIT. When you use a cleanup procedure, make sure you have it within the main.prg, where it's always on the program stack and therefore can't be "forgotten". Prevent modal states through Messageboxes without timeout. I think print previews can also be a stopper.
Bye, Olaf.
Cryl, okay, QUIT would also destroy references to office and other OLE servers, but itself would not handle any tidy up in them. Still, as I already said twice QUIT does not QUIT directly, it triggers QueryUnload() of forms and Destroy of objects. So these tasks would then need to be part of the classes you have handling office.
You don't need a cleanup routine as QUIT already triggers all clean up routines in all class instances running. The proof is below.
I have solved the problem.
None of the discussion above was directly relevant. I'm already doing the transaction testing and rollbacks, the try catch endtrys, the clear events, the on shutdown (various). NONE had the slightest effect. But I'm inclined to award the points to jrbbldr who - by mentioning the modal forms - forced me to look in the right places.
By a process of elimination I found two guilty parties. Both objects I included in my standard FORM class. One is the cryptpak component which allows me to use encryption and hashing throughout my applications. This is an activex component which we can't modify. Closing forms with it normally presents no problems but when it's on a bunch of forms you're trying to close in an errortrapping situation, it somehow becomes a "dangling object" and simply will not let go. I solved that problem by removing it from the form class and declaring it as a universal object at the beginning of my apps. That way it only needs a single release and stops causing problems.
The other was the microsoft timer object, which I also include in my standard form class. That too caused a problem IF THE TIMER WAS STILL ACTIVE when you tried to force a shutdown. The solution here was to explicitly disable the timer as part of the standard form release code.
Business Accounts
Answer for Membership
by: jrbbldrPosted on 2009-08-18 at 09:49:33ID: 25125168
Many times this problem is caused by a Modal form being open when the shutdown is attempted.
If that is the case, then you need to make certain that your Shutdown closes all forms.
Good Luck