Form.Close problem

[Rob Agar]

hi all,

I have a problem which I believe others have experienced before, but as far
as I can see has not been resolved.

Basically, the form refuses to close. Neither clicking the 'X' button nor
calling Form.Close works. The Closing event is not thrown. The form
contains a number of controls, some of which are derived from UserControl.
The problem can be reproduced by setting certain child control properties,
but they're pretty innocuous things like the title of a graph, so I can't
see how they'd have such an effect...

A few people seem to have come across this problem. Is it a bug known to
MS? (if anyone knows of a relevant KB article I'd be very grateful! I have
looked, but couldn't find anything)

cheers,
Rob

 

[Shakir Hussain]

Call

Application.ExitThread();

in File->Exit

 

[Rob Agar]

that's rather an extreme solution! =)

R

Call

Application.ExitThread();

in File->Exit

 

[Sunny]

Does your app use threads? Do you update the controls from the threads?

Sunny

 

[Miha Markic [MVP C#]]

Hi,

Call

Application.ExitThread();

in File->Exit

I would suggest this option like a last resource - it abrubtly exits.
Instead try pinpointing the source of problem.

 

[Chien Lau]

This is a well-known bug that was introduced in RC1 of the .NET
framework. Pretty much all of my WinForms applications have "workaround
code" to get around this bug. For some odd reason, Microsoft refuses to fix
this particular bug despite the fact that people have been complaining about
it for years. Here is more information + advice:

http://www.jelovic.com/weblog/e41.htm

 

[Rob Agar]

ever heard of it happening *without* manually removing controls? The code
I'm having trouble with has user controls on other user controls on tabs etc
etc, but they're never removed. Do you reckon adding & removing columns in
a datagrid could cause it?

I take it there's no KB article on MSDN, is there...?

cheers!
Rob

 

[Chien Lau]

ever heard of it happening *without* manually removing controls?

Yes. This happened to me when using the SoftwareFX charting component,
ChartFX. This chart object offers the user the ability to manually type
values into a grid which then updates the chart. At some point, I'm guessing
that the component instantiates a little text box for the user to use when
typing. When the user is done typing, that little text box is destroyed.
Although I can't be certain, I'm guessing that at some point during the
process, the charting component creates and destroys a UserControl-derived
object. Since the designer of the control wasn't aware of this ridiculous
Microsoft bug, and because the control doesn't provide me with any feedback
as to when the control is being removed, there is absolutely no way for me
to workaround this bug. If the user decides to use this particular feature
of the chart, the form window won't close and the user is forced to use an
abrupt "End Task" to manually kill the process of the WinForms app. In the
end, I chose to simply disable this particular feature in the chart rather
than trying to teach users to manually kill the process.

The fact that this problem hasn't been addressed after all of these years is
completely unacceptable.

 

[Rob Agar]

Yes. This happened to me when using the SoftwareFX charting component,
ChartFX. This chart object offers the user the ability to manually type
values into a grid which then updates the chart. At some point, I'm guessing
that the component instantiates a little text box for the user to use when
typing. When the user is done typing, that little text box is destroyed.
Although I can't be certain, I'm guessing that at some point during the
process, the charting component creates and destroys a UserControl-derived
object. Since the designer of the control wasn't aware of this ridiculous
Microsoft bug, and because the control doesn't provide me with any feedback
as to when the control is being removed, there is absolutely no way for me
to workaround this bug. If the user decides to use this particular feature
of the chart, the form window won't close and the user is forced to use an
abrupt "End Task" to manually kill the process of the WinForms app. In the
end, I chose to simply disable this particular feature in the chart rather
than trying to teach users to manually kill the process.

ah hah! I'm using the ChartFX control too! Do you mind if I include your
post in a bug report I'm going to send to SoftwareFX?

I've found that the problem manifests after the user changes the graph
title, so I guess it's the little popup text edit box that's causing the
problem.

The fact that this problem hasn't been addressed after all of these years is
completely unacceptable.

uh huh. I can't understand why MS would ignore a problem this bad.

 

[Chien Lau]

ah hah! I'm using the ChartFX control too! Do you mind if I include your

post in a bug report I'm going to send to SoftwareFX?

Please do! That would be awesome if they added a workaround to their
component...

 

[Software FX Support]

Rob, Chien.

I work at SoftwareFX and saw your posting, we have seen this issue
sporadically in our tests so it is very difficult to know if a code change
will fix it. I just rechecked and edited the chart's title up to 5 times on
a test app but was not able to reproduce this bug.

I can follow JMW's suggestion and check all the events we are catching but
it would be very helpful if you have an app where you can easily reproduce
this issue, then we can send you a version of our DLLs to see if that fixes
this problem.

Regards,

JC
Software FX Support

 

[Rob Agar]

SoftwareFX have promised to include the workaround in the next ChartFX
service pack

btw, they say they can't reproduce the problem using .NET 1.1. Do you know
if it manifests in 1.1? I only have .NET 1.0...

R

 

[Chien Lau]

SoftwareFX have promised to include the workaround in the next ChartFX

service pack

btw, they say they can't reproduce the problem using .NET 1.1. Do you know
if it manifests in 1.1? I only have .NET 1.0...

Yes, it manifests in 1.1 as well. My personal opinion is that SoftwareFX
will have difficulty coming up with a workaround. The workaround to this
problem would require their component to navigate up through the hierarchy
of windows to the top level form. On that top level form, the
OnControlRemoved() method must be called when ChartFX destroys its internal
window(s)/control(s). The problem, of course, is that OnControlRemoved() is
'protected', not 'public', so I'm not sure if the ChartFX component will be
able to call this method to implement the workaround.

In my own code, all of my top level forms implement a custom interface
called "IWinFormsHack" which I define as follows:

internal interface IWinFormsHack{
void DoOnControlRemoved(Control ctl);
}

...where my implementation of DoOnControlRemoved() simply delegates to
the form's OnControlRemoved(). Since I can ensure that my top level forms
implement this interface, the workaround becomes possible. Since ChartFX
can't make any assumptions about the user's top level form, it becomes much
more difficult for them to implement the workaround.

 

[rockclimber90]

I can't reproduce the problem consistently in .NET 1.1, even the
sample from
Dejan Jelovic (as is) doesn't do it.

I'm prety sure however, that I've seen it happen, just not when I want
to reproduce it :-(

What we did now was unhook all event handlers before removing the
control as suggested by JMW, since this can't do any bad.

If the workaround presented by Dejan Jelovic is necesary, then Chien
is right, I don't think we can do it from our control as we can not
call OnControlRemoved.

We could provide you with a new event fired right before the control
is removed and give it to you, however, this will be very obscure and
hard to explain to most of our users.

If we determine that the problem still happens in .NET 1.1 even after
unhooking the events, we may decide to add this event anyway, so far I
can't so I'm holding-up this change.

If you are interested, contact our support dept., get the HotFix and
if you can reproduce the problem with the latest hotfix and .NET 1.1
then let me know but please tell me how to reproduce it, I had cramps
in my hand the other day from clicking the close buton so many times
trying to reproduce this.

Frank