Sorin,
IMHO there is no reason to use quit within production code in the runtime environment which is where Dennis was seeing the cancelled wait window.
A main.prg can be as simple as this code fragment, my actual one isn't much more complicated.
on error ...
on shutdown EndApp()
StartApp()
do mymenu.mpr
read events
EndApp()
return
function StartApp()
return
function EndApp()
on shutdown
clear events
close data all
return
Cannot quit Foxpro is caused by not having an ON SHUTDOWN handler in place with a READ EVENTS still active.
The "problem" with the help file is this statement (from VFP8, although 6 and 7 have similar admonishments)
Always use QUIT to terminate a Visual FoxPro session...is patently not true.
>I don't know if it's the simplest for Dennis to avoid using QUIT, it may be, however I think QUIT has its value. My approach is to have a Cleanup() function/method execute ON SHUTDOWN, which Cleanup ends in a QUIT. This avoids having the user face a message like "Cannot quit VFP" when shutting down Windows with the VFP app still open. With something like ON SHUTDOWN Do Cleanup.prg this will not happen.
>Yes, QUITing while testing in development sucks. However, for the development, I would call the same Cleanup upon exiting the app, which evaluates the VFP version and if in development, it would RETURN after cleaning-up and resetting the environment.
>
>Sure, if QUIT bothers you then don't use it, but I still have to develop as if QUIT would happen anywhere during the app runtime. Maybe the message here should be stop using QUIT improperly :), but do use it in runtime. And BTW, I don't see anything wrong with the help file on QUIT.