Best way to quit application

[steve3739]

Hi all,
After looking at the FAQs and prior posts regarding the best way to quit an application, the following code seems like a simple way to go:

***Simplified Main Program***********************
on error do errorhandle
on shutdown do confirmquit && asks user if they really want to quit
do menu1
do form1
read events

***shutdown OR menu choice OR form button calls confirmquit.prg which issues a "clear events" command, and program control returns here...

on error
on shutdown
on key
clear all &&clears all variables and windows (but leaves project manager if open)
close databases all
if _vfp.startmode=0
_screen.windowstate=2 &&maximized
set sysmenu to default
set status bar on
endif
cancel
******************************************
Before I start making changes to my forms and prgs, does this look like a clean way to quit? Or am I missing something important?

Thanks for any comments or suggestions.
Steve - occasional programmer

 

[Mike Gagnon]

Have you tried just these simple commands.

Close database all
clear events
quit

Everything else should clean up on it's own.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[alvechurchdata]

I've also got the following lines in my shutdown so as I get a decent development environment back even if the app has crashed.

Do While Txnlevel() > 0
  Rollback
Enddo

Push Key Clear

Set Carry Off
Set Confirm On
Set Date British
Set Escape On
Set Exact On
Set Exclusive Off
Set Help on  
Set Logerrors On
Set Notify On
Set Safety On
Set Status Bar On
Set StrictDate To 0
Set SysMenu To Default
Set Talk On
Set Trbetween Off

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Mike Lewis]

Steve,

Here's my version of the code that comes after READ EVENTS.

IF NOT glRunTime
  * Only do this if we are in the 
  * development environment
  IF WEXIST("Standard")
    SHOW WINDOW "Standard"	
  ENDIF 	&& bring back main toolbar
  SET SYSMENU TO DEFAULT  && and VFP menu
  ON ERROR
  ON SHUTDOWN 
  SET SAFETY ON
  SET STATUS BAR ON
  IF FILE("MyProject.PJX")
    MODIFY PROJECT MyProject NOWAIT	
  ENDIF 
  SET HELP TO 
  _screen.Picture = ""
ELSE
  * Do this if in runtime
  ON SHUTDOWN
  QUIT 
ENDIF

Of course, the details will vary, depending on what settings you make in the main application. For example, if you don't switcb off the status bar, you won't need SET STATUS BAR ON.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[alvechurchdata]

For example, if you don't switcb off the status bar, you won't need SET STATUS BAR ON.

I don't trust my memory that far. I've not SET CARRY ON in an app for years but I still SET CARRY OFF in my closedown routine against the day when I do use that feature again.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[steve3739]

Thank you all for your responses and suggestions. It looks like we are all pretty much on the same page. I made the changes last night, and everything seems to be working as planned. The CONFIRMQUIT.PRG just checks for any unsaved changes, and then asks the user if they really want to quit. If the response is YES, CLEAR EVENTS is issued. The CONFIRMQUIT.PRG can be called from the menu, close box, or the exit button on various forms.

The only real change I made was the line "if _vpf.startmode=0" as that doesn't seem to distinguish between starting the app in the developement mode or the compiled exe. Instead, I check for a dummy file which is only on the development machine.

Thanks again. This forum has been incredibly helpful for a non-pro like me who needs to come up with solutions for our small office.

Steve

 

[Mike Lewis]

Steve,

Re checking to see if you are in development or run time, here's the code I use:

glRunTime = (VERSION(2) = 0)

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[TamarGranor]

Any reason you're asking the user if she really wants to quit? Isn't it enough for her to click the X or choose File-Exit?

Tamar (who has user interfaces on her mind lately)

 

[Stella740pl]

Tamar,

It's only my personal opinion, but the only thing more annoying than application constantly asking if you really want to quit is actually quitting it by mistake mid-work, when what you really wanted was only to maximize it.

Stella

 

[steve3739]

To Mike: Thanks for the tip on using version(2)=0. I knew there must be something like that, but never could find it.

To Tamar and Stella: You both have good points. However, all the users here are "older" and have a tendency to start madly clicking when they get too many windows open on the desktop. I've never had a complaint about confirming to quit, but I can't count the number of times I've heard an anguished AARRRHHH!!! from somewhere in the office when someone closed an app by mistake. We all open our apps first thing in the morning, and ususally keep them runing all day, so for us it makes sense to confirm a quit. Everything here is for in-house use only, so I tend to do the things that work best for our group. And the user interface is the only thing the users really know or care about. Over the years, I've learned that no one, and I mean NO ONE, uses help systems, and I keep the user interface as simple as possible -- the fewer options, buttons, and menus, the better. (For a younger generation that's grown up with computers and multitasking, more complexity probably is not an issue).

Steve

 

[alvechurchdata]

glRunTime = (VERSION(2) = 0)

Just to add to Mike's tip. You'll see he's storing the status into a global flag. That comes in very useful all through the app. Just to give three examples:

If glRunTime is .F. then:

I skip the login process. I know it only takes a couple of seconds to login but it's a couple of seconds saved many, many times a day.

All reports are PRINT PREVIEW because I do not want to keep waiting for the printer when I'm testing.

I use surrogate keys as Primary keys. Users mustn't see them at runtime but I need them for testing.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Mike Lewis]

Geoff,

Another thing to add to the list of run time /development tme differences is error handling. At run time, I want users to see my frienly error message and have an error log generated. In the development environment, I just want the Cancel / Suspend / Ignore message.

Like you, I skip the login dialogue in development. Given the vast number of times you run the app when testing, this can be a great time-saver.

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[alvechurchdata]

In the development environment, I just want the Cancel / Suspend / Ignore message.

I may well steal this idea<g>.

Better still - just reroute the error handler to SET STEP ON when an error crops up.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Mike Lewis]

just reroute the error handler to SET STEP ON when an error crops up.

Hmm. The problem there is that sometimes you know you can ignore the error. Also, often you know the cause of the error as soon as you see the message, and you just want to cancel so that you can fix it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[steve3739]

To Geoff and Mike:
Thanks for the tips on the additional uses for the global runtime flag. Good ideas.

To Tamar and Stella re Confirm on Quit: I always have a user table which holds info like full name, login id, color and sound settings, priviledges, etc. This table would be a good place to store a Confirm on Quit flag.

Steve

 

[alvechurchdata]

The problem there is that sometimes you know you can ignore the error

Having had time to reflect perhaps I would get annoyed if the Trace window popped up on every error. Especially on something like "File not found".

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Olaf Doschke]

Regarding the "Do you really want to Quit" problem, ideally you should only annoy the user with such a message, if there is something pending, eg. a record change not saved, an open data input form etc.

There are even other situations where one can easily click the X by mistake, eg. if a report preview is open maximized and you want to close that and not the application.

Besides that, you can reset your favourite Settings by having an environement class that saves actual settings at init and restores them at destroy. That can be reused for each datasession.

Besides that, you can echo all settings by opening the options dialog and holding down the SHIFT key while quitting the dialog with the OK button. The corresponding set commands are then echoed to the command window.
This way you can generate code that resets any change made by your applications and copy that to an tidy up routine.

At least it works with VFP7. I didn't got that working with VFP9!? Did that change?

Bye, Olaf.

 

[alvechurchdata]

The corresponding set commands are then echoed to the command window

Took me a while (and advice from here) to discover that VFP 9 sends these to the Debug Output window not to the Command Window.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Olaf Doschke]

Ah! Thanks Geoff,

It's a good idea to echo it there instead of the command window. You just need to know it...

Bye, Olaf.

 

[Mike Lewis]

Olaf,

Regarding the "Do you really want to Quit" problem, ideally you should only annoy the user with such a message, if there is something pending, eg. a record change not saved, an open data input form etc.

If there is unsaved data, you should not display a "Do you really want to quit?" message. The message should be: "Do you want to save your changes to this <customer, invoice, whatever>?"; with three options: Yes, No, Cancel. If they answer Cancel, you don't quit.

Come to think of it, "Do you really want to ..." is not particularly friendly. I'd prefer: "Are you sure you want to ... "?

Just my humble o.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk