Is this always happening or do you see a pattern, for example after you used some feature, when you try to quit while a report preview is shown, or anything in that direction?
You can intercept errors in many ways and also suppress them. Problem is this "Cannot quit FoxPro" message looks like an error message, quacks like an error message, yet it's not a duck. And not an error.
Most probably you are in a state where a READ EVENTS wasn't yet paired up with a CLEAR EVENTS, which you surely can't control as a user. It means a typical quit menu item does a READ EVENTS and usually works, but if you do that in a state where a messagebox is active or a report preview - the term is modal state, that doesn't really work, and then VFP gets into a state where it refuses to quit.
If that happens to a VFP developer while developing and he can at least manage to suspend the program, so the command window will show up again (which automatically hides when code runs), you can type in two things that usually work out well:
and then
The first command just ensures that clicking the X close button, or using the File->Exit menu item, or executing the command QUIT just do their default behavior, or - as the term SHUTDOWN suggests correctly, if you shut down the computer. Even if a READ EVENTS currently is active a QUIT then works. But there are harder cases I've seen - the hardest case is that the command window is shown and you can type commands, but entering them does not execute them. That becomes apparent, if you do something that should have a direct visual effect, like using ? 'hello, world' should output hello world on the screen. Then you're quite busted to get any grip, the debugger could help, but of course that's even further from what you can use as a user, the debugger isn't part of the runtime of a VFP application at all. So let's stop here.
All in all, as a user you don't have the development environment including its command window and debugger. So no chance for you, but to terminate the process in the task manager. If the app is not quitting because it's in the READ EVENTS state and you have no means to cause the CLEAR EVENTS, there is no chance for you. It could be that the quit/exit menu item does CLEAR EVENTS and that's not bad design, but in cases that happens when - lets oversimplyfiy this, the READ EVENTS does not detect it's matched with a CLEAR EVENTS, but some exit code also removes the menu so you can't repeat using it and causing CLEAR EVENTS... you're stuck.
Overall, there's a design flaw in that application that most probably only effects exactly that: Quitting the application. If everything else works okay, it's mainly an inconvenience you can only report to the developer or company and describe how to reproduce it, ideally. So a developer can fix an issue.
If you're the developer the simplest program you can run is just READ EVENTS. If you do that and try to exit VFP you get that "Cannot Quit Visual Foxpro" message. You can also see if you establish a simple ON ERROR Messagebox("error") the error event (ON ERROR) isn't triggered. It's a message, but not an error.
You have a case of not programming with one simple rule in mind: Always open and close brackets, like using both READ EVENTS and CLEAR EVENTS. Like creating objects and also releasing them eventually. Or - in developer speak - destroy or "kill" them. And there is what the task manager offers to any user (unless the task manager is taken away from users by group policies), the emergency stop, to end tasks and processes. It's your only tool from outside, and in special cases even that doesn't get a grip on a process and only a shutdown/restart fixes it.
Chriss
