Trapping the CLOSE button on a form 1

[sdocker]

Is there a way to intercept the CLOSE button before it releases the form.

Any references to a variable in the UNLOAD produces an Unknown Member error.

I would like to remind the user to save any changes before it is too late.

I don't want to disable it.

Thanks,
Sam

 

[vgulielmus]

Put your code in the Queryunload event

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[sdocker]

Thanks vgulielmus,

Undoubtedly the quickest and most to the point answer I have ever received.

You saved me hours of searching for a solution.

Thank you,
Sam

 

[vgulielmus]

I just logged on, answering to another post.

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[Koen Piller]

Hi,
also in the Release() method you must check if it is OK to destroy your form. So I suggest:
add a method OK2DESTROY in you form.
Now:
in QueryUnload:
Thisform.Check4changes()
If Not Thisform.OK2Destroy()
Nodefault
Endif

in Release()
LOCAL llRet as Booleanr
if not thisform.OK2Destroy(m.llRet
nodefault
endif

in OK2Destroy:

lparameters tcTable
local lcTable, llRet, lnAnswer


if empty(m.tcTable)
lcTable = alias()
else
lcTable = m.tcTable
endif
with thisform
llRet = ! .check4changes(m.lcTable)

if llRet = .f. &&found uncommitted changes
lnAnswer = messagebox( "Do you want to save the data?", 4+16+0+0, "Take care!", 0 ) && Yes = 6, No = 7, Cancel = 2
do case
case lnAnswer = 6
.AllUpdated = tableupdate(.t.)
if type(' .AllUpdated')='N'
.AllUpdated = iif( .AllUpdated=0,.f.,.t.)
endif
case lnAnswer = 7
.AllUpdated = tablerevert(.t.)
if type(' .AllUpdated')='N'
.AllUpdated = iif( .AllUpdated=0,.f.,.t.)
endif
case lnAnswer = 2

endcase
endif
endwith

return m.llRet


Regards,

Jockey(2)

 

[Mike Lewis]

Just to add a couple of points to Vilhelm-Ion's reply:

- If you want to prevent the form from closing (for example, if there are unsaved edits), call NODEFAULT from the QueryUnload.

- The QueryUnload fires whenever you attempt to close the form by user action. This includes clicking the X button, but also hitting Cltr+F4, selecting Close from the control menu, closing the entire application, or even shutting down Windows. But it does not fire if you call THISFORM.Release.

I hope this is of interest.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

> But it (it being QueryUnload) does not fire if you call THISFORM.Release.
Its important to point that out. That is the reason Jockey suggested adding a separate user defined method to check, whether conditions are met to close the form or not and calling (quite like asking) that method from both QueryUnload and Release.

One more thing to it: Before QueryUnload is called the form property ReleaseType is set and you can determine what caused QueryUnload. Eg in your case of clicking the close button or close menu command it's 1, in case the form is released by releasing a variable holding the (only/last) form reference, the value is 0 and in case Foxpro exits, which rather means windows is shutdown, the value is 2.

It's important to not, because this is a form property otherwise useless, its value only is of importance in the QueryUnload. It's a design error to not make this a QueryUnload event parameter, because that makes it very unobvious, there is info about the closing reason.

The reason for Release always is just one: It was called - it never happens automatically. So in the release method you can assume your form is closed by your own code and you want the form to close. The OK2Destroy check, as Jockey names it, could also be done outside of Release, that's a matter of taste, but it makes sense to do as Jockey suggests, as you then react in the central two methods/events for form closing and channel these into one central method. There also is the closable property you might set, but that disables the close button, which is not what you want. Again a matter of taste.

The importance of Thisform.ReleaseType is, if its value is 2. You typically then don't want to prevent a windows shutdown, actually you can't relay or prevent it forever. Current Windows versions then ask the user, if he wants to shutdown anyway and depending on settings Windows even shuts down, if the user doesn't react. Also in case of notebooks the emergency shutdown happening on low battery always will occur. So you better react to that QueryUnload in a automatic save or revert (what suits you better) and close.

Bye, Olaf.

 

[Koen Piller]

Hi,

I forget to mention the credit to my OK2Destroy method and coding as showed is for Andy Kramek. Please note.

Thanks,

Jockey(2)