在Designer视图中渲染派生用户控件

Question

I have a UserControl hierarchy that looks something like this:

public class BaseClass : UserControl
{
    protected Label[] Labels;
    public BaseClass(int num)
    {
        Labels = new Label[num];
        for(int i=0; i<num; i++)
        {
            Labels[i] = new Label();
        }
    }
}

And in a different file:

public class DerivedClass : BaseClass
{
    public DerivedClass() : base(2)
    {
        // Do stuff to the location, size, font, text of Labels
    }
}

This structure is designed so that the BaseClass handles core logic and DerivedClass handles display logic. The number of Labels needs to be variable (different DerivedClasses will have different num values).

My problem is that I would like the designer view to show the UserControl as it would look after the display adjustments. There are several problems -- first, if BaseClass lacks a default constructor, then the DerivedClass's designer view just fails. Even if I add a default constructor, the designer view shows the layout of DerivedClass without the various display changes.

I'm not interested in using the designer view to change the Controls. I'm not opposed to it, but the fact that Labels are in an Array seems to prevent the designer view from being able to access them. I am simply interested in being able to see the effects of my display layout code in the DerivedClass.

Answer 1

There appears to be a limitation in the Windows Forms designer that prevents the currently designed class' own constructor from running - only the parent class(es) constructors are fired.

If I take your example:

public partial class BaseControl : UserControl
{
    public BaseControl()
    {
        InitializeComponent();
    }


    protected Label[] Labels;

    public BaseControl(int num) : base()
    { 
        Labels = new Label[num]; 
        for(int i=0; i<num; i++) 
        { 
            Labels[i] = new Label(); 
        } 
    }

}

public class DerivedControl : BaseControl
{

    public DerivedControl() : base(5)
    {
        Controls.Add(Labels[0]);

        Labels[0].Text = "Hello";
        Labels[0].Location = new System.Drawing.Point(10, 10);

    }

}

Then, when I look in the designer for Derived Control, I see nothing. However, if I add the following control derived from DerivedControl:

public class GrandchildControl : DerivedControl
{

    public GrandchildControl() : base() { }

}

And, after building my project, look at that in the designer (Visual Studio 2010), I see:

It appears to be a feature of the designer. According to this blog post on MSDN blogs (which is quite old)

1. Form1 must be built before you can add another Form, say Form2, that visually inherits from it. This is because the designer for Form2 has to instantiate Form1, not System.Windows.Forms.Form. This also explains why if you open Form2 in the designer, attach a debugger to Visual Studio and set a breakpoint in Form1's InitializeComponent, the breakpoint does get hit.

2. There is a comment above InitializeComponent that warns you against modifying it manually. This is because the designer needs to parse this code, and it has some limitations as to what it can parse. It is generally guaranteed to parse whatever it serialized in there, but not arbitrary code that you may add.

3. If you are manually (through code) adding a control to the form in the constructor or in the Load event handler, the control doesn't show up in the designer. This is because the designer doesn't parse that - it only parses InitializeComponent.

The only way I have ever got this to reliably work is to either move all of my code into a method that get's called by InitializeComponent (and occasionally, you have to remember to stick it back in when it get's "overwritten" by the designer) or to do as I've done above and create a GrandchildUserControl to fake the constructor call of the actual control I'm interested in.

FWIW I believe this is a consequence of 1) and 3) and is almost certainly a work-around of something that is by design.

Point 1) also raises a great investigative technique for these situations - you can actually launch another instance of Visual Studio and attach to the first instance of Visual Studio and debug the method calls running there. This has helped me troubleshoot several designer issues in the past.

Answer 2

As dash pointed out, the designer create an instance of the base class, then parses the InitializeComponent method and executes its instructions. This means that there is no simple way to have it execute the code in the derived classes' constructors (you should parse the constructor and execute its instructions).

You have to be careful that the solution of having the derived class' specific instructions grouped in a method which is called inside InitializeComponent works only if the method is generic enough to be defined in the base class, since the designer is working with an instance of this base class. This means that if the method is declared as virtual in the base class that will be the one that is executed, whilst if there is no such method in the base class the designer will crash.

You could do something along these lines. Define this method in the base class:

    protected void CreateLabels(int num)
    {
        Labels = new Label[num];
        for(int i=0; i<num; i++)
        {
            Labels[i] = new Label();
            this.Controls.Add(Labels[i]);
        }
    }

Then you have to call it in the InitializeComponent of your derived control passing the proper value of num.

All of your settings are then to be moved to the InitializeComponent method, too. Of course, if they can be generalized, you can write the same kind of method.

The main drawback of this approach is the fact that everything will work until you don't modify your control from the designer, because your InitializeComponent will be messed up. You can control this kind of behaviour by implementing a serializer for your controls. Ie you have to implement a class BaseControlCodeDomSerializer derived from System.ComponentModel.Design.Serialization.CodeDomSerializer redefining the Serialize method someway like this:

    public override object Serialize(IDesignerSerializationManager manager, object value)
    {
        BaseControl aCtl = value as BaseControl;
        if (aCtl == null)
            return null;
        if (aCtl.Labels == null)
            return null;
        int num = aCtl.Labels.Length;

        CodeStatementCollection stats = new CodeStatementCollection();

        stats.Add(new CodeSnippetExpression("CreateLabels(" + num.ToString() + ")"));

        return stats;
    }

Finally, you can simply associate the Serializer to the Control with this Attribute:

[DesignerSerializer("MyControls.BaseControlCodeDomSerializer", typeof(CodeDomSerializer))]