e.Cancel = True in MDI Child Closing event

[Oenone]

I'm writing an application with various MDI child forms.

In the Closing event of many of the forms, I have code that asks the user
whether he is sure he wants to close the form, because it contains unsaved
data. If the user clicks "No" then the code sets e.Cancel = True, which
cancels the closure. This works just great.

But when the user closes the MDI parent form, the cancellation seems to be
completely ignored. The MessageBox appears, I click "No", but the form (and
the application) closes anyway.

In VB6, aborting the closing in a form's QueryUnload event would cancel the
closure of the application in this circumstance. I'm eager to try to obtain
this behaviour in VB.NET as I'm worried about people losing work that they
have entered into these forms.

Is there any way to achieve this?

Many thanks,

 

[Charles Law]

The expected behaviour is that if you attempt to close an MDI parent then
the Closing event of each MDI child will fire. If any one of these child
forms sets e.Cancel = True then no further Closing events will be fired, and
the MDI parent will not close. I have this scenario and it works as
described.

Can you confirm that with one MDI parent and one Child, clicking the MDI
Parent close button does not fire the child closing event?

Charles

 

[Oenone]

The expected behaviour is that if you attempt to close an MDI parent
then the Closing event of each MDI child will fire. If any one of
these child forms sets e.Cancel = True then no further Closing events
will be fired, and the MDI parent will not close. I have this
scenario and it works as described.

Hmm, I just set up a project to test this and it worked exactly as you
described.

There must be something else going on in my real application -- I'll
investigate.

Thanks for your help,

 

[Oenone]

There must be something else going on in my real application -- I'll
investigate.

In the Closing event of the MDI Container form, I had some code which closed
the entire application down. This was a hang-over from the VB6
implementation and was unsurprisingly causing the behaviour I described.
With this removed it's all working perfectly.

Thanks again,