473,895 Members | 2,811 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Weird Problem: Closing MDI Parent re-directed to MDI Child

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
Nov 20 '05 #1
10 4039
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
-----------------

"Charles Law" <bl***@nowhere. com> wrote in message
news:Oh******** ******@TK2MSFTN GP09.phx.gbl:
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


--
Outgoing mail is certified Virus Free.
Checked by AVG Anti-Virus (http://www.grisoft.com).
Version: 7.0.230 / Virus Database: 263.1.2 - Release Date: 6/7/2004
Nov 20 '05 #2
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
"Ken Tucker [MVP]" <vb***@bellsout h.net> wrote in message
news:eV******** ******@TK2MSFTN GP11.phx.gbl...
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
-----------------

"Charles Law" <bl***@nowhere. com> wrote in message
news:Oh******** ******@TK2MSFTN GP09.phx.gbl:
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


--
Outgoing mail is certified Virus Free.
Checked by AVG Anti-Virus (http://www.grisoft.com).
Version: 7.0.230 / Virus Database: 263.1.2 - Release Date: 6/7/2004

Nov 20 '05 #3
Charles,
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, 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!
and the parent
remains open. I am then unable to close the application. Are you canceling the first MDI Child's Form.Closing event?
What should happen, is that the main MDI form should close, taking the child forms with it. This is normal .NET behavior, unless you have an event, such as Closing,
canceling the operation.
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. 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.
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. 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

"Charles Law" <bl***@nowhere. com> wrote in message
news:Oh******** ******@TK2MSFTN GP09.phx.gbl... 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

Nov 20 '05 #4
Hi 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.OnClosin g(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.Componen tModel.CancelEv entArgs)

MyBase.OnClosin g(e)

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

' First copy the controls to the selected list, to avoid
' modifying the later loop whilst it is executing
m_SelectedContr ols.AddRange(Co ntrols)

For Each ctl As Control In m_SelectedContr ols
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]" <Ja************ @msn.com> wrote in message
news:eq******** ******@TK2MSFTN GP10.phx.gbl...
Charles,
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,

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!
and the parent
remains open. I am then unable to close the application. Are you canceling the first MDI Child's Form.Closing event?
What should happen, is that the main MDI form should close, taking the

child
forms with it.

This is normal .NET behavior, unless you have an event, such as Closing,
canceling the operation.
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.

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.
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.

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

"Charles Law" <bl***@nowhere. com> wrote in message
news:Oh******** ******@TK2MSFTN GP09.phx.gbl...
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


Nov 20 '05 #5
Charles,
This removes the controls prior to the form closing.

Does any of this make it clearer? 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_SelectedContr ols?

Hope this helps
Jay

"Charles Law" <bl***@nowhere. com> wrote in message
news:uj******** ******@TK2MSFTN GP10.phx.gbl... Hi 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.OnClosin g(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.Componen tModel.CancelEv entArgs)

MyBase.OnClosin g(e)

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

' First copy the controls to the selected list, to avoid
' modifying the later loop whilst it is executing
m_SelectedContr ols.AddRange(Co ntrols)

For Each ctl As Control In m_SelectedContr ols
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]" <Ja************ @msn.com> wrote in message
news:eq******** ******@TK2MSFTN GP10.phx.gbl...
Charles,
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,

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!
and the parent
remains open. I am then unable to close the application.

Are you canceling the first MDI Child's Form.Closing event?
What should happen, is that the main MDI form should close, taking the

child
forms with it.

This is normal .NET behavior, unless you have an event, such as Closing,
canceling the operation.
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.

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.
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.

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

"Charles Law" <bl***@nowhere. com> wrote in message
news:Oh******** ******@TK2MSFTN GP09.phx.gbl...
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



Nov 20 '05 #6
Hi Jay

m_SelectedContr ols 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.
Does one of your controls or another handler of the Closing event cancel the Closing event?
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]" <Ja************ @msn.com> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. .. Charles,
This removes the controls prior to the form closing.

Does any of this make it clearer? 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_SelectedContr ols?

Hope this helps
Jay

"Charles Law" <bl***@nowhere. com> wrote in message
news:uj******** ******@TK2MSFTN GP10.phx.gbl...
Hi 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.OnClosin g(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.Componen tModel.CancelEv entArgs)

MyBase.OnClosin g(e)

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

' First copy the controls to the selected list, to avoid
' modifying the later loop whilst it is executing
m_SelectedContr ols.AddRange(Co ntrols)

For Each ctl As Control In m_SelectedContr ols
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]" <Ja************ @msn.com> wrote in message news:eq******** ******@TK2MSFTN GP10.phx.gbl...
Charles,
> 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,
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!

> and the parent
> remains open. I am then unable to close the application.
Are you canceling the first MDI Child's Form.Closing event?

> What should happen, is that the main MDI form should close, taking
the child
> forms with it.
This is normal .NET behavior, unless you have an event, such as Closing, canceling the operation.

> 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.
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.

> 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.
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

"Charles Law" <bl***@nowhere. com> wrote in message
news:Oh******** ******@TK2MSFTN GP09.phx.gbl...
> 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
>
>



Nov 20 '05 #7
Charles,
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. 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.
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. 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" <bl***@nowhere. com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. .. Hi Jay

m_SelectedContr ols 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.
Does one of your controls or another handler of the Closing event cancel the
Closing event?


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]" <Ja************ @msn.com> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..
Charles,
This removes the controls prior to the form closing.

Does any of this make it clearer?

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_SelectedContr ols?

Hope this helps
Jay

"Charles Law" <bl***@nowhere. com> wrote in message
news:uj******** ******@TK2MSFTN GP10.phx.gbl...
Hi 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.OnClosin g(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.Componen tModel.CancelEv entArgs)

MyBase.OnClosin g(e)

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

' First copy the controls to the selected list, to avoid
' modifying the later loop whilst it is executing
m_SelectedContr ols.AddRange(Co ntrols)

For Each ctl As Control In m_SelectedContr ols
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]" <Ja************ @msn.com> wrote in message news:eq******** ******@TK2MSFTN GP10.phx.gbl...
> Charles,
> > 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,
> 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!
>
> > and the parent
> > remains open. I am then unable to close the application.
> Are you canceling the first MDI Child's Form.Closing event?
>
> > What should happen, is that the main MDI form should close, taking the > child
> > forms with it.
> This is normal .NET behavior, unless you have an event, such as Closing, > canceling the operation.
>
> > 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.
> 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.
>
> > 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.
> 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
>
> "Charles Law" <bl***@nowhere. com> wrote in message
> news:Oh******** ******@TK2MSFTN GP09.phx.gbl...
> > 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
> >
> >
>
>



Nov 20 '05 #8
Jay

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.

Did I ask if there are any Exceptions being raised that is causing the
Closing Event to end unexpectedly?
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]" <Ja************ @msn.com> wrote in message
news:uS******** *****@TK2MSFTNG P10.phx.gbl... Charles,
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. 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.
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.

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" <bl***@nowhere. com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
Hi Jay

m_SelectedContr ols 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.
Does one of your controls or another handler of the Closing event cancel
the
Closing event?


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]" <Ja************ @msn.com> wrote in message news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..
Charles,
> This removes the controls prior to the form closing.
>
> Does any of this make it clearer?
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_SelectedContr ols?

Hope this helps
Jay

"Charles Law" <bl***@nowhere. com> wrote in message
news:uj******** ******@TK2MSFTN GP10.phx.gbl...
> Hi 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.OnClosin g(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.Componen tModel.CancelEv entArgs)
>
> MyBase.OnClosin g(e)
>
> ' When the form closes, remove all controls from the Controls list
> and
> ' dispose them first
> m_SelectedContr ols.Clear()
>
> ' First copy the controls to the selected list, to avoid
> ' modifying the later loop whilst it is executing
> m_SelectedContr ols.AddRange(Co ntrols)
>
> For Each ctl As Control In m_SelectedContr ols
> 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]" <Ja************ @msn.com> wrote in

message
> news:eq******** ******@TK2MSFTN GP10.phx.gbl...
> > Charles,
> > > 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,
> > 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! > >
> > > and the parent
> > > remains open. I am then unable to close the application.
> > Are you canceling the first MDI Child's Form.Closing event?
> >
> > > What should happen, is that the main MDI form should close, taking the
> > child
> > > forms with it.
> > This is normal .NET behavior, unless you have an event, such as

Closing,
> > canceling the operation.
> >
> > > 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.
> > 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.
> >
> > > 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.
> > 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
> >
> > "Charles Law" <bl***@nowhere. com> wrote in message
> > news:Oh******** ******@TK2MSFTN GP09.phx.gbl...
> > > 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
> > >
> > >
> >
> >
>
>



Nov 20 '05 #9
Charles,
One word: Encapsulation!
The ShowStuff object displays information
about the Device object, but knows nothing of the Device object per se 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.
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. 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.GetInv ocationList 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.Ge tInvocationList ()
[Delegate].Remove(DoStuff Event, 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 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. I am suggesting that you do!
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. 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" <bl***@nowhere. com> wrote in message
news:eH******** *****@tk2msftng p13.phx.gbl... Jay

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.

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


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]" <Ja************ @msn.com> wrote in message
news:uS******** *****@TK2MSFTNG P10.phx.gbl...
Charles,
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.

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.
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.

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" <bl***@nowhere. com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
Hi Jay

m_SelectedContr ols 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.

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

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]" <Ja************ @msn.com> wrote in

message news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..
> Charles,
> > This removes the controls prior to the form closing.
> >
> > Does any of this make it clearer?
> 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_SelectedContr ols?
>
> Hope this helps
> Jay
>
> "Charles Law" <bl***@nowhere. com> wrote in message
> news:uj******** ******@TK2MSFTN GP10.phx.gbl...
> > Hi 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.OnClosin g(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.Componen tModel.CancelEv entArgs)
> >
> > MyBase.OnClosin g(e)
> >
> > ' When the form closes, remove all controls from the Controls list
> > and
> > ' dispose them first
> > m_SelectedContr ols.Clear()
> >
> > ' First copy the controls to the selected list, to avoid
> > ' modifying the later loop whilst it is executing
> > m_SelectedContr ols.AddRange(Co ntrols)
> >
> > For Each ctl As Control In m_SelectedContr ols
> > 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]" <Ja************ @msn.com> wrote in
message
> > news:eq******** ******@TK2MSFTN GP10.phx.gbl...
> > > Charles,
> > > > 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,
> > > 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! > > >
> > > > and the parent
> > > > remains open. I am then unable to close the application.
> > > Are you canceling the first MDI Child's Form.Closing event?
> > >
> > > > What should happen, is that the main MDI form should close, taking the
> > > child
> > > > forms with it.
> > > This is normal .NET behavior, unless you have an event, such as
Closing,
> > > canceling the operation.
> > >
> > > > 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.
> > > 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.
> > >
> > > > 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.
> > > 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
> > >
> > > "Charles Law" <bl***@nowhere. com> wrote in message
> > > news:Oh******** ******@TK2MSFTN GP09.phx.gbl...
> > > > 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
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Nov 20 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
1473
by: Freddie | last post by:
Hi, I've been playing around with asyncore for one of my projects, currently using it to fetch HTTP pages without blocking things. Having a few issues, though. With the code below, I would start a new async_http instance with "async_http(url, returnme)". If it encountered a redirect, that object would start a new one as "async_http(url, returnme, seen=self._seen)" to remember what URLs it had seen. The problem is that after a while...
4
2438
by: flupke | last post by:
Hi, I have a gui (made in wxPython) that enables a user to connect to a server and issue some commands. The problem occurs when i try to disconnect the client. It exits but it doesn't return to the prompt. I have to push Ctrl-C in order to have it exit completely. The GUI is closed though. This is a piece of code from the main class that connects to the server and starts a thread that handles the connection: =======================...
3
2331
by: ThunderMusic | last post by:
Hi, I'm trying to have a MSN Messenger like form/app closing behavior. When I click on the X button, I only want the form to disappear and when I double-click on the notify icon or right-click on it and choose Open from the context menu, I want the form to reappear. For that, I got the point covered. Even when the form is minimize, the behavior is like MSN Messenger. But one problem arose. When I close the form (the first time), it...
2
1265
by: Cc | last post by:
hi, while I making my own class library using odbc.net I encounter strange problem in this class Public Sub New() ' some code doing openning connection end sub
0
2070
by: Alan Silver | last post by:
Hello, I have two weird problems here. I have a master page file that works absolutely fine. When I load it up in VWD, I get a couple of weird (to me) errors. First, I get the error "Unrecognized tag prefix or device filter 'asp'" on the third line shown below... <head runat="server">
4
2022
by: PiotrKolodziej | last post by:
hi I have a thread that downloades a file. Problem is : Not all files are beeing downloaded. I observed that only the small files are beeing downloaded correctly. I also cant download two files in a row. I got to Exit and run the program again to even start downloading. The second problem i interprett as iam not closing something ( but don't know what ). For the first problem i have no idea what is wrong.Here is the download thread Maybe...
20
2185
by: ongaro.admin | last post by:
Hi, I'm experiencing a strange problem with .mdb files. We have two buildings connected by optical fiber (a single LAN). Everything works perfect with any file, any size, any application software. The hardware has been tested several times. Viruses, trojans and so on: clean for sure. The problem is that .mdb files (_only .mdb files_) often don't open, are very slow, or even get crashed and corrupted. The weird is that even copying them...
4
5249
nitindel
by: nitindel | last post by:
Hi Guys... I am looking for a functionality of closing the POP UP window that i have opened from a Parent window....Whenver i Close the Parent window.. I mean to say... Whenver i close the parent window ..the pop up shold also be closed automaticallly...
2
1467
by: Thiago Macedo | last post by:
Hello everybody. I'm experiencing an strange problem with WinForms which someone, if possible, could help me to deal with. We have a windows application which serves as a menu, calling other forms in different class library, all called as Modal Dialog. In one of this forms, I have another call to a Modal. When this second modal is closed, automatically is closed the form who called it. I can't understand how this is happening. After the...
0
9990
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
10847
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10475
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9653
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
8030
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7181
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
6072
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4695
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
3298
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.