What's the best way to QUIT a program 1

[jrumbaug]

I hate to admit it, but I'm not sure of the proper way to QUIT. Nor am I sure of the READ EVENTS, CLEAR EVENTS relation and the placement of code before, after or between. Where is the best place to put the QUIT command? These questions came up after adding some suggested code to make things better. Here's a stripped down example:

*** MAIN.PRG
ON SHUTDOWN Do ProperShutDown
*** START PROGRAM
DO FORM First NAME frmFirst LINKED
READ events
CLEAR EVENTS
*** End of Program

**********************************
PROCEDURE ProperShutDown
**********************************
ON SHUTDOWN
CLEAR ALL
CLOSE ALL
IF _vfp.StartMode = 0
CANCEL
ELSE
QUIT
ENDIF
ENDPROC && ProperShutDown


********* CODE In FrmFirst.Command1.CLICK
** I experimented with these 4 commands
RELEASE ThisForm
** With just Release ThisForm, the program ended, but none
** of the 'SHUTDOWN code' from the main.prg fired and I
** have to go to PROGRAM on menu bar and click on CANCEL
QUIT
** Adding Quit almost worked. but got an error saying
**could not CLEAR ALL because COMMAND1 was in use.
CLEAR EVENTS
** adding CLEAR EVENTS seems to work fine. 'SHUTDOWN code'
** is fired. Do not have to go to PROGRAM on menu bar and
** click on CANCEL
CANCEL
** adding CANCEL ends the program. I do not have to click
** on CANCEL under PROGRAM. But the 'SHUTDOWN code' does
** not fire.


Is using the CLEAR EVENTS command the proper way to end the form and return control to MAIN.PRG ? Is there another prefered way. When would you place code between READ EVENTS and CLEAR EVENTS?

Jim Rumbaugh

 

[craigsboyd]

You don't need the Clear Events after your Read Events in the code you posted above. Read Events is known as a Foundation Read, you can only have one active at a time (and usually you would only have that one in your main.prg). Now in your First.scx you would want to put "Clear Events" in either the Destroy event (preferred place for it) or in the Unload event.

Now, what happens is this...the read events creates a event processing loop (think it of a do loop that won't allow your application to exit) and this loop will continue until a Clear Events is issued. In your form (First.scx) you will probably have a Exit button somewhere that fires thisform.release or you will just let the user click the [X] to close the form...this in-turn will fire the Unload and Destroy events. You will have a "Clear Events" in one of those which will clear the Foundation Read (Read Events) that you issued in your main.prg. AND, since you haven't any code after that Read Events your application will now begin to exit. This in-turn fires the ProperShutDown procedure which will clean up any variables in memory, close any open forms, tables, etc., and then either Quit or Cancel.

The reason for issuing either Quit or Cancel is simple. You don't want the VFP IDE to close if you are just debugging the application so you have it check _vfp.startmode and if you are running within VFP IDE then CANCEL is used to just shutdown the application you are debugging rather than the entire IDE (which is what would happen if you issued QUIT), but if your application is running from your EXE then you actually do want it to QUIT so you call that instead.

There is more to this depending on how complex/advanced your application is. But, it's a really good start and will serve you well in your VFP applications.

http://www.sweetpotatosoftware.com

 

[jrumbaug]

Thank you Craig,
You've answered many questions. But I'd like to add what I think is a minor correction. I can only get the ProperShutDown code to run if a QUIT is issued. I can't just let the 'program come to the end of code'.

Here's what I've learned
1) I should issue a CLEAR EVENTS from the first/last called form or else I'll have to go to PROGRAM and click on CANCEL.
2) It does not work to enter CLEAR EVENTS from the same program that issued the READ EVENTS.
3) The ON SHUTDOWN code only executes if a QUIT command is issued.
4) It is best to have the QUIT command after READ EVENTS in the MAIN prog. If the QUIT command is not in the MAIN prog, problems can come up since the Object with the QUIT command is not released before executing the ON SHUTOWN code in MAIN prog

*** My New Preffered way to start and end
*** MAIN.PRG
ON SHUTDOWN Do ProperShutDown
*** START PROGRAM
DO FORM First NAME frmFirst LINKED
READ EVENTS && CLEAR EVENTS found in frmFirst
QUIT
*** End of Program

I'm happy now. Thanks a lot.
Jim Rumbaugh

 

[Mike Lewis]

Jim,

May I jump in with a couple of comments:

1) I should issue a CLEAR EVENTS from the first/last called form or else I'll have to go to PROGRAM and click on CANCEL.

It's not a question of doing it in the first/last called form. You issue CLEAR EVENTS at whatever point(s) in your user interface at which the user signals that they want to close down. This will typically be the Exit command in the File menu, or a Quit button on a form or toolbar.

Also, the Program menu is only available in the development environment. It is not something the user will see in the application.


2) It does not work to enter CLEAR EVENTS from the same program that issued the READ EVENTS.

I'm not sure why you are saying that. It is not the physical location of the CLEAR EVENTS that counts, but rather the point at which it is executed.

3) The ON SHUTDOWN code only executes if a QUIT command is issued.

Not so. The ON SHUTDOWN executes whenever an attempt is made to close the app, by any means. That includes the user clicking on the X button on the main window title, or right-clicking on the taskbar button and choosing Close, or even attempting to close Windows while the app is running.

For more info on this point, you might like to read my article, "How to avoid the Cannot Quit Visual FoxPro message", at

http://www.ml-consult.demon.co.uk/foxst-07.htm

4) It is best to have the QUIT command after READ EVENTS in the MAIN prog. If the QUIT command is not in the MAIN prog, problems can come up since the Object with the QUIT command is not released before executing the ON SHUTOWN code in MAIN prog

Not necessarily. Again, it is not the physical location that counts, but the point in time at which it is executed. Also, you don't absolutely have to a QUIT. You could let the code run off the end of the program, but a QUIT is generally preferable.

I know it's all a bit confusing, but you are obviously on the right track. You just need to nail down some of these details.

Mike



Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[DSummZZZ]

I may as well jump on the bandwagon.

3) The ON SHUTDOWN code only executes if a QUIT command is issued

The way I understand it is ON SHUTDOWN executes when VFP is terminating. Be it in a standalone app or in the IDE.
But if a CANCEL is issued, and you return from an app to the IDE, ON SHUTDOWN doesn't fire until you then close VFP.
So you may want to add a call to the cleanup routine after the READ EVENTS, at least temporarily while you're doing the developing.

-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Mike Lewis]

Dave,

The way I understand it is ON SHUTDOWN executes when VFP is terminating. Be it in a standalone app or in the IDE.
But if a CANCEL is issued, and you return from an app to the IDE, ON SHUTDOWN doesn't fire until you then close VFP

That is exactly my understanding as well.

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[jrumbaug]

Dave and Mike

Let me ammend my statement.
During development, ON SHUTDOWN code only executes if a QUIT command is issued, otherwise it executes when you shut down the IDE.

Maybe I'm splitting hairs, but my hacking showed that during development, the ON SHUTDOWN code does not execute if the code just comes to an end and returns to the IDE. Nor did it execute by clicking the X to close the window.
But the compiled program would run the ON SHUTDOWN code when closed by any means.

Jim Rumbaugh