Developer Forum

For some reason, when I click the X to close my MDI parent form, the action
appears to be re-directed to one of the MDI child forms, and the parent
remains open. I am then unable to close the application.

What should happen, is that the main MDI form should close, taking the child
forms with it. There is code to loop through the child forms, remove the
controls on each of them, and then close the form, but this code should
execute only when the user clicks a specific menu option.

What actually happens is when I click the X to close the main form, the
first of the child forms has all its controls removed, and nothing else
happens.

I realise that I haven't given much to go on, but I just wondered if anyone
had any thoughts/suggestions of what could cause this.

TIA

Charles

Hi,

Sorry I haven't been able to reproduce that behavior. Is it possible
you have code in forms closing event preventing the app from closing
properly?

Ken
-----------------

Hi Ken

The exact procedure that causes this effect is

Start main app
Open MDI child form
Close MDI child form
Open MDI child form
Click X to close main app

The last step, in this scenario, now causes the currently open MDI child
form to clear its controls and nothing else. If I were to click the X after
the first open then all would be well.

I have an event handler in the main MDI parent form, with 'Handles
MyBase.Closed', but this is never called after following the steps above (it
is called if I click the X after the first open).

What could be going on?

Charles

Charles,
action
I would expect when you close the MDI parent that it will be re-directed to
all of your MDI child forms! As the MDI parent cannot close until all the
MDI child's are closed.

In other words. MDIParent.Close automatically causes MDIChild.Close!

Are you canceling the first MDI Child's Form.Closing event?

child
This is normal .NET behavior, unless you have an event, such as Closing,
canceling the operation.

The Form.Closing & Form.Closed event occurs for MDI child forms whether they
are closed explicitly via code or implicitly via the MDI parent being
closed.

Which event are you removing all the controls in?


Are you handling the Form.Closing & Form.Closed events or did you override
the Form.OnClosing & Form.OnClosed methods. If you overrode OnClosing, did
you remember to call the base methods?

Hope this helps
Jay



action
child
anyone

i Jay

I see now why it goes to the child forms first. I should have thought of
that ;-)

At the MDI form level I handle the Form.Closed event. At the child level, I
have overridden the OnClosing method, the first line of which is
MyBase.OnClosing(e). It is in the OnClosing override that I remove all the
controls from the form.

I have simplified the process for making it behave oddly:

Start MDI form app
Open child form
Close child form
Click X to close app (nothing happens)

whereas

Start MDI form app
Open child form
Click X to close app (closes as normal)

Opening the child form loads some user controls and adds event handlers to
an object on the main form, where methods of the user controls are the
target.

The OnClosing method looks like this

<code>
Protected Overrides Sub OnClosing(ByVal e As
System.ComponentModel.CancelEventArgs)

MyBase.OnClosing(e)

' When the form closes, remove all controls from the Controls list
and
' dispose them first
m_SelectedControls.Clear()

' First copy the controls to the selected list, to avoid
' modifying the later loop whilst it is executing
m_SelectedControls.AddRange(Controls)

For Each ctl As Control In m_SelectedControls
Controls.Remove(ctl)

ctl.Dispose()
Next ctl

End Sub
</code>

This removes the controls prior to the form closing.

Does any of this make it clearer?

Charles


"Jay B. Harlow [MVP - Outlook]" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
to
they

harles,
What is not clear is why you are removing the controls the explicitly? The
Form class will implicitly remove the controls for you.

Does one of your controls or another handler of the Closing event cancel the
Closing event?

Is this VS.NET 2002 or VS.NET 2003?

As Ken suggested, I am not able to recreate this behavior, even with
explicitly removing the controls...

What type of collection is m_SelectedControls?

Hope this helps
Jay

"Charles Law" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
I
the
should
the
else
override
did
parent
the
should
the
else

i Jay

m_SelectedControls is an ArrayList, and I am using VS 2003.

I'm removing the controls explicitly because they are user controls that
sink events, and ultimately, I know that as part of this process I must
unhook the handlers from the events. This is part of problem 2 (of 3), that
if I close a child form that is servicing events, without unhooking the
handlers, then when the event is next raised it still calls the code in the
old handler, and if the object that was the target of the handler has been
disposed an exception is thrown to the effect that I cannot access a control
that has been disposed.

the

None of my controls or handlers attempt to cancel the Closing event.

With regard to reproducing the behaviour, I wonder if the fact that the
controls sink events is significant. If I do the same thing w/o adding
controls to the form then all is well.

Charles


"Jay B. Harlow [MVP - Outlook]" < XXXX@XXXXX.COM > wrote in message
news:% XXXX@XXXXX.COM ...
the
level,
the
to
list
message
re-directed
the
Closing,
whether
the

harles,
I would not remove the controls explicitly to unhook the handlers, I would
simply assign Nothing to the UserControl's SelectedObject property, where
the SelectedObject property unhooks the existing handler. Where the
SelectedObject property is a property of the correct name & type for the
type of "domain object" the user control displays. For example if I have a
Person object and a PersonControl that displays a Person object. The
PersonControl would have a SelectedPerson property. Within the
SelectedPerson property I would remove any handlers of the existing Person
before assigning the handlers for the new object.

I don't have a good test setup right now to test if having a user control
handle an external object's events is messing up the Closing, I would be
surprised if it does.

Did I ask if there are any Exceptions being raised that is causing the
Closing Event to end unexpectedly?

Hope this helps
Jay

"Charles Law" < XXXX@XXXXX.COM > wrote in message
news:% XXXX@XXXXX.COM ...
that
the
control
The
of
handlers
the
all
being
form,
OnClosing,
the
remove
form,
if

ay

I'm not sure I follow you when you talk about a SelectedObject.

If I can translate your example into my own, let's say I have a Device
object and a ShowStuff object. The ShowStuff object displays information
about the Device object, but knows nothing of the Device object per se [as I
am writing this I think a light is coming on]. As such, the handlers are
attached outside the ShowStuff and Device objects, so the ShowStuff object
does not know what events it is servicing and cannot therefore call
RemoveHandler. I should clarify that I am not removing the objects manually
in order to detach the handlers, as I realise that this does not work; it
was just a precursor to implementing this process.

If I had a SelectedObject property, what would it contain that could remove
the handlers w/o knowing which events had been attached? This question is
actually the subject of another post: 'How to iterate through a list of
sender events and detach all receiver handlers when given only the sender
and receiver as Objects'.

As you say, though, the fact that the handlers are not being detached is
probably not the cause of the app not closing.

I have just traced through the app again, and there are two ways that the
child form can be created:

Case 1.
a. User clicks toolbar button to create new, blank child form
b. User drags usercontrol onto form from toolbox

Case 2.
a. User selects file from open file dialog
b. File is opened and child form is recreated from file (xml)

In case 1, I can close the child form and close the app as normal. In case
2, I can close the child form but the app won't close. However, I cannot see
that the two methods are doing anything substantially different. The same
utility functions for creating the form and instantiating the usercontrol
are used in both cases.



I don't think you did, but anyway, there aren't any exceptions thrown. I
have all exceptions set to break into the debugger when they are thrown.

Charles


"Jay B. Harlow [MVP - Outlook]" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
been
cancel
message
cancel
thought
all
the
Controls
MDIChild.Close!
taking
nothing
taking
nothing
wondered

harles,
One word: Encapsulation!

If ShowStuff knows nothing about the Device object, how does it know what to
display??

I would expect at the very least that ShowStuff would know about DeviceBase
abstract base (mustinherit) class or the IDevice interface, then
polymorphically be able to display any type of Device (derived class) that
may be able to be given to it. Any events that ShowStuff needed to be
implemented would be part of DeviceBase or IDevice.

Yes I read your other question, Herfried gave you the field you need.
However! I would have recommended encapsulation and have ShowStuff be
responsible for adding & removing any handlers that it owns. If you need to
use the DoStuffEvent to remove the handlers you can use
Delegate.GetInvocationList to get all the handlers on a Delegate, then use a
For Each to remove each one.

Something like (untested):
For Each handler As [Delegate] In DoStuffEvent.GetInvocationList()
[Delegate].Remove(DoStuffEvent, handler)
Next

Again I would only use this as a last resort! As I find it a little
anti-encapsulation, in that the object handling the event might have cleanup
that needs to be done before it stops handling the event, and the above
routine will not give the object handling the event a chance to do this
clean up...

This is especially importing if you show the Device in multiple ShowStuff
user controls at one time, where the user can open & close windows at will,
on the same document...

I am suggesting that you do!

see
Sounds like something in your 2b logic. 2b or not 2b that is the question.

Can you describe or show how you are opening the file & creating the child
form?

Hope this helps
Jay




"Charles Law" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
I
manually
remove
see
that
must
would
where
a
Person
the
control
that
must
the
in
the
explicitly?
form,
until
code
you
form,
the
code