Are there problems with Nesting Forms

[Guest]

I've always been a bit annoyed by the over 200 methods and properties that
are inherited from Form, so I came up with a technique to get around this. I
create the Form in the designer, and then I wrap the Form class in an outer
class that acts as my dialog. This lets me keep the interface limited to the
the properties and methods that pertain directly to my dialog. I'm about to
implement this, but I'm afraid of any potential negative side effects. One
thing that worries me, is will the nested form plug into the message loop
correctly. So far the code runs ok, but I'm afraid of an unsuspecting side
effect nailing me at a critical time, i.e. during a demo. Here's an example
of what I'm doing.

public class ActionDialog:IDisposable
{
private ActionForm _form = new ActionForm();

//ActionDialog Definition....

public DialogResult ShowDialog(IWin32Window owner)
{
//Setup Form...
return _form.ShowDialog(owner);
}

public void Dispose()
{
_form.Dispose();
}
private class ActionForm : Form
{
//ActionForm definition....
}
}

 

[Nicholas Paldino [.NET/C# MVP]]

This will work fine. The only problem with this is that you won't be
able to use your form where parameters of type Form are expected. If you
can live with this, then you are fine.

However, I honestly wouldn't do this though, as you are going to find
(as the amount of reuse becomes greater) that you will need to expose more
and more from the underlying form, at which point, you will just end up
deriving from Form anyways.

It's excessive code which isn't going to improve the maintainability,
performance, or usability of your code.

Hope this helps.

 

[Guest]

This will work fine. The only problem with this is that you won't be
able to use your form where parameters of type Form are expected. If you
can live with this, then you are fine.

However, I honestly wouldn't do this though, as you are going to find
(as the amount of reuse becomes greater) that you will need to expose more
and more from the underlying form, at which point, you will just end up
deriving from Form anyways.

It's excessive code which isn't going to improve the maintainability,
performance, or usability of your code.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I've always been a bit annoyed by the over 200 methods and properties that
are inherited from Form, so I came up with a technique to get around this.
I
create the Form in the designer, and then I wrap the Form class in an
outer
class that acts as my dialog. This lets me keep the interface limited to
the
the properties and methods that pertain directly to my dialog. I'm about
to
implement this, but I'm afraid of any potential negative side effects.
One
thing that worries me, is will the nested form plug into the message loop
correctly. So far the code runs ok, but I'm afraid of an unsuspecting
side
effect nailing me at a critical time, i.e. during a demo. Here's an
example
of what I'm doing.

public class ActionDialog:IDisposable
{
private ActionForm _form = new ActionForm();

//ActionDialog Definition....

public DialogResult ShowDialog(IWin32Window owner)
{
//Setup Form...
return _form.ShowDialog(owner);
}

public void Dispose()
{
_form.Dispose();
}
private class ActionForm : Form
{
//ActionForm definition....
}
}

Thanks for the advice. I see your point, and I will consequently take your advice.