What's the state of play with “Visual Inheritance”

Question

We have an application that has to be flexible in how it displays it\'s main form to the user - depending on the user, the form should be slightly different, maybe an extra

Answer 1

I am studying towards the (admittedly soon-to-be-obsoleted) MCAD, and part of the WinForms element was Visual Inheritence.

I personally have had no major problems with it, however, there are considerations to take in to account.

For me, the main problem has always initialization.. You need to remember that the designer cannot/does not instantiate forms in the same way it does at run time (similarly, it cannot do this with web dev, which is why care is needed with custom control rendering).

Also, once a form is changed, a complete re-build of the project is required in order to propagate the changes to the form to the child forms that inherit from it.

I personally have seen no evidence to suggest that it has been "shunned". AFAIK, its still good practice to exercise code re-use where possible. Visual inheritance provides that.

May I suggest creating a new question with the actual problems you are having, with sample code? We can then look at it to see if we can get it working and explain why :)

Answer 2

I often stumble upon such problems in Visual Studio. In many cases MSVS forms designer fails to render form correctly. Back in the days I worked with WinForms I had to do all kind of weird tricks to enable some complex scenarios. However I think that using visual inheritance is very beneficial and should not be thrown away regardless of MSVS designer bugs.

Answer 3

I think I've found a way how to avoid this problem.

Don't hook the Form_Load Event in your parent form, this will break the designer.

Also don't take the Default empty constructor away from Visual Studio in the Parent Form. If you want to have Dependency Injection, create another constructor.

Like this:

public ProductDetail()
{
    InitializeComponent();
}

public ProductDetail(ISupplierController supplierController) : base()
{
    InitializeComponent();
    this.supplierController = supplierController;
}

You can then still do this from your inherited Form:

public NewProduct(ISupplierController supplierController)
    : base(supplierController)
{
    InitializeComponent();
}

This worked for me so far, and I had some weird designer issues too.

cheers, Daniel

Answer 4

Read this: http://cs.rthand.com/blogs/blog_with_righthand/archive/2005/11/10/186.aspx

AFAIK, there are still issues with Visual Inheritance and objects that rely on collections for the design elements, typically grid controls etc. I believe MS still have removed the possibility of changing f.ex. a GridView in an inherited form/usercontrol etc. But other controls like TextBox, Form, UserControl, Panel etc. should work as expected.

I've so far had no problem with VI using 3rd party grid controls myself, but you have to be careful, in particular, removing items from collections MUST be avoided.

Answer 5

I thought they had more or less sorted the desktop designer issues in 2005. Have you tried the usual culprits?

• No abstract control types
• No constructor arguments in any form
• Initialisation moved to Form_Load as opposed to the Ctor
• No controls in the same project as the usercontrol/form that they are put inside
• Close all documents -> Clean -> Rebuild
• Restart VS

I seemed to think that as long as you did all of the above it worked..... mostly.

Answer 6

I've seen some problems in VS2005 with this. They were mostly due to problems with construction of the forms-objects in the designer. There were issues with code that tried to access the database from the form-constructors etc.

You can debug issues like this by starting a second instance of visual studio and loading up the first instance in the debugger. If you set breakpoints in your code you can then debug what happens in the designers in the first instance.

Another problem I can remember was generics in form classes

public class MyForm<MyObject> : Form

this won't work