As part of a fully non-modal (well almost) application I'm working on, I wanted to be able to ask the user if they wanted to save or discard their changes when a form closed reguardless of how or when the form was closed. I set out to trap for every type of FORM closing. However, I found this to be a little more complicated than I expected.

Below are the results I found using the DO FORM command with both the (NAME varname LINKED) and unlinked versions and also using a class definition of the same form with createobject().

All of the tests were done on VFP 8.0 (released) and were done on individual forms or class definitions only. I don't use FormSets and did not check to see how they close.

Assuming the FORM'S file name is Employee_Edit.scx or the class definition name is Employee_Edit.

CLOSE TYPE					RESULT			R Type	
****************************************************************************
Release Method					Release + Destroy	0

RELEASE WINDOW "EMPLOYEE_EDIT"			QueryUnload + Destroy	1
Close (x)					QueryUnload + Destroy 	1
CLEAR WINDOWS					QueryUnload + Destroy 	1
RELEASE WINDOWS					QueryUnload + Destroy 	1
Quit						QueryUnload + Destroy 	2
Shutting Down (Restarting)  Windows XP Pro	QueryUnload + Destroy 	2
(you'll only get 15 seconds or so)

Releasing the (NAME varname LINKED) 		Destroy			0 
(NAME varname LINKED) goes out of scope		Destroy			0	
Relasing the Object var				Destroy			0
Object Var goes out of scope			Destroy			0

The only sure way (that I've found) to catch a form during closing is to call it's QueryUnload explicitly and to have the QueryUnload contain code in it to determine if the form should close. If you let the (NAME varname LINKED) or the Object var go out of scope, you can't catch the FORM's closing in a way that will help. Putting NODEFAULT in, or RETURNING .f. from the Destroy Event won't stop the form from closing.

Putting NODEFAULT in the QueryUnload will.

In the Form's QueryUnload Event:

IF NOT (what ever you want to check or ask the user)
	NODEFAULT && Stop here and don't do the Destroy  
	RETURN .F.
ELSE
	RETURN .T.
ENDIF 

Additionally, ALL coded attemps to close the FORM will need to call the QueryUnload().

IF Thisform.QueryUnload()
	Thisform.Release
ENDIF


IF Thisform.QueryUnload()
	RELEASE (NAME varname LINKED) && or RELEASE object var
ENDIF


IF Thisform.QueryUnload()
	RELEASE WINDOW Employee_edit
ENDIF

This means that in your ON SHUTDOWN routine, you will need to loop through all of the open forms you want to check and call the QueryUnload Event before allowing the app to Quit.

However, If you've linked a form to a property of the form that calls it (as is popular in some of the VFP books), then you'll need to call the QueryUnload of the called form, from the form that called it. If you don't, the calling form's linked property may go out of scope first and you won't get a chance to check.

As an example: Form1 calls form2 and links form2 to a property on form1. If form1 closes before form2, then the linked property on form1 will go out of scope and form2 will close. However, form2 will close with the Destroy event only and then it's to late.

It seems to me a lot of this could have been avoided if VFP ALWAYS called QueryUnload every time a FORM was closed.

As in:
Release + QueryUnload + Destroy (when release was called)

or

QueryUnload + Destroy (for all other attempts to close the form)

In this way, queryunload could always give you place to do your house cleaning at a point where you could stop the closing if needed.