I replaced child forms with user controls and indeed the problem goes away.

Many thanks !

Hmm well, user controls doesn't fix the problem if I add more level of nesting...

Since the bug reported to Microsoft was caused by a MessageBox, i did try to set e.RaiseErrorEvent = false in the CellDataError event to prevent the display of the error messagebox. The result is there is no more infinite loop, but a new very strange behavior:  the focus is in the "outside" textbox but keystroke are typed into the grid cell !?!

To compare behavior, I tried using a comboEditor set to LimitToList, which is even more deeply nested than the grid, and it behave correctly, I can't leave the combo when clicking away, even if clicking in parent containers.

So it seems a grid bug to me.

I attached another sample to demonstrate this

Hi,

You are correct that nesting like this will cause the issue. This is the same issue that I reported to Microsoft, and it's a bug in the DotNet framework. Unfortunately, there is nothing we can do about this.

I recommend that if you are going to nest controls, you use a base class for your controls that do not rely on the ContainerControl class. So, for example, instead of using UserControl (which derives from ContainerControl), you could simply derive your controls from the Control class.

This means you won't be able to see your controls in the designer, but it's the only way I know of to avoid the infinite loop of dialogs.

If this is a problem you face often, then what I would do is create two configurations of your application and then use a #if so that your controls derive from UserControl in one  configuration which you can use to design them, and then use a separate configuration where your controls derive from Control for release to your users.

Hi Andreas,

Sorry, but I don't have the sample any more and it looks like the Microsoft Feedback page is no longer available. As far as I can recall, the issue occurs when you have nest ContainerControls and you try to show a MessageBox or other dialog inside the Leave event of a control inside the nested container. So I would think it should be fairly easy to reproduce - assuming Microsoft hasn't already fixed it.

@Mike Saltzman: In our company we have a similar problem with SelectNextControl invoked by our code. I'm very interested in the sample code you've provided Microsoft to prove the error. Is it possible that you email me that sample? Sorry for OT posting here, but it was the only chance for me to contact you.

Greetz
Andy Fischer

I don't know how common it is, but I attached a sample project to my report to Microsoft that demonstrates the bug with a couple of ContainerControl-derived controls and no Infragistics controls. It's very clearly a bug in the DotNet Framework.

The problem occurs with 2 levels of nesting. That is, a ContainerControl inside another ContainerControl.

There's nothing inherently bad about using more levels of nested ContainerControls as far as I know. This one bug is the only issue I am aware of.

My advice is to simply avoid ContainerControl nesting. You can next control without having those controls be ContainerControls.

Thank you Mike.

I tried googling but did not find much results about this issue, beside your bug report.

Is this common knowledge in Winforms that nested UserControl/ContainerControl should be avoided ? Do you have any other references stating this ?

How many levels of nesting is considered bad, 3 and more  ? It is really not that hard to reach 3 levels in a screen with some tabs...