How can I get Visual Studio 2008 Windows Forms designer to render a Form that implements an abstract base class?

Question

I engaged a problem with inherited Controls in Windows Forms and need some advice on it.

I do use a base class for items in a List (selfmade GUI list made of a panel) and some inherited controls that are for each type of data that could be added to the list.

There was no problem with it, but I now found out, that it would be right, to make the base-control an abstract class, since it has methods, that need to be implemented in all inherited controls, called from the code inside the base-control, but must not and can not be implemented in the base class.

When I mark the base-control as abstract, the Visual Studio 2008 Designer refuses to load the window.

Is there a way to get the Designer work with the base-control made abstract?

Solution 1

I KNEW there had to be a way to do this (and I found a way to do this cleanly). Sheng's solution is exactly what I came up with as a temporary workaround but after a friend pointed out that the Form class eventually inherited from an abstract class, we SHOULD be able to get this done. If they can do it, we can do it.

We went from this code to the problem

Form1 : Form

Problem

public class Form1 : BaseForm
...
public abstract class BaseForm : Form

This is where the initial question came into play. As said before, a friend pointed out that System.Windows.Forms.Form implements a base class that is abstract. We were able to find...

Proof of a better solution

• Inheritance Hierarchy:

  • System.Object
    • System.MarshalByRefObject (public **abstract** class MarshalByRefObject)
      • System.ComponentModel.Component
        • System.Windows.Forms.Control
          • System.Windows.Forms.ScrollableControl
            • System.Windows.Forms.ContainerControl
              • System.Windows.Forms.Form

From this, we knew that it was possible for the designer to show a class that implemented a base abstract class, it just couldn't show a designer class that immediately implemented a base abstract class. There had to be at max 5 inbetween, but we tested 1 layer of abstraction and initially came up with this solution.

Initial Solution

public class Form1 : MiddleClass
...
public class MiddleClass : BaseForm
... 
public abstract class BaseForm : Form
... 

This actually works and the designer renders it fine, problem solved.... except you have an extra level of inheritance in your production application that was only necessary because of an inadequacy in the winforms designer!

This isn't a 100% surefire solution but its pretty good. Basically you use #if DEBUG to come up with the refined solution.

Refined Solution

Form1.cs

public class Form1
#if DEBUG
    : MiddleClass
#else 
    : BaseForm
#endif
...

MiddleClass.cs

public class MiddleClass : BaseForm
... 

BaseForm.cs

public abstract class BaseForm : Form
... 

What this does is only use the solution outlined in "initial solution", if it is in debug mode. The idea is that you will never release production mode via a debug build and that you will always design in debug mode.

The designer will always run against the code built in the current mode, so you cannot use the designer in release mode. However, as long as you design in debug mode and release the code built in release mode, you are good to go.

The only surefire solution would be if you can test for design mode via a preprocessor directive.

Solution 2

@smelch, There is a better solution, without having to create a middle control, even for debug.

What we want

First, let's define the final class and the base abstract class.

public class MyControl : AbstractControl
...
public abstract class AbstractControl : UserControl // Also works for Form
...

Now all we need is a Description provider.

public class AbstractControlDescriptionProvider<TAbstract, TBase> : TypeDescriptionProvider
{
    public AbstractControlDescriptionProvider()
        : base(TypeDescriptor.GetProvider(typeof(TAbstract)))
    {
    }

    public override Type GetReflectionType(Type objectType, object instance)
    {
        if (objectType == typeof(TAbstract))
            return typeof(TBase);

        return base.GetReflectionType(objectType, instance);
    }

    public override object CreateInstance(IServiceProvider provider, Type objectType, Type[] argTypes, object[] args)
    {
        if (objectType == typeof(TAbstract))
            objectType = typeof(TBase);

        return base.CreateInstance(provider, objectType, argTypes, args);
    }
}

Finally we just apply a TypeDescriptionProvider attribute to the Abastract control.

[TypeDescriptionProvider(typeof(AbstractControlDescriptionProvider<AbstractControl, UserControl>))]
public abstract class AbstractControl : UserControl
...

And that's it. No middle control required.

And the provider class can be applied to as many Abstract bases as we want in the same solution.

* EDIT * Also the following is needed in the app.config

<appSettings>
    <add key="EnableOptimizedDesignerReloading" value="false" />
</appSettings>

Thanks @user3057544 for the suggestion.

---

Solution 3

@Smelch, thanks for the helpful answer, as I was running into the same issue recently.

Following is a minor change to your post to prevent compilation warnings (by putting the base class within the #if DEBUG pre-processor directive):

public class Form1
#if DEBUG  
 : MiddleClass 
#else  
 : BaseForm 
#endif 

Solution 4

I've got some tips for people who say the TypeDescriptionProvider by Juan Carlos Diaz is not working and don't like the conditional compilation neither:

First of all, you may have to restart Visual Studio for the changes in your code to work in the form designer (I had to, simple rebuild didn't work - or not every time).

I will present my solution of this problem for the case of abstract base Form. Let's say you have a BaseForm class and you want any forms based on it to be designable (this will be Form1). The TypeDescriptionProvider as presented by Juan Carlos Diaz didn't work for me also. Here is how I made it work, by joining it with the MiddleClass solution (by smelch), but without the #if DEBUG conditional compiling and with some corrections:

[TypeDescriptionProvider(typeof(AbstractControlDescriptionProvider<BaseForm, BaseFormMiddle2>))]   // BaseFormMiddle2 explained below
public abstract class BaseForm : Form
{
    public BaseForm()
    {
        InitializeComponent();
    }

    public abstract void SomeAbstractMethod();
}


public class Form1 : BaseForm   // Form1 is the form to be designed. As you see it's clean and you do NOTHING special here (only the the normal abstract method(s) implementation!). The developer of such form(s) doesn't have to know anything about the abstract base form problem. He just writes his form as usual.
{
    public Form1()
    {
        InitializeComponent();
    }

    public override void SomeAbstractMethod()
    {
        // implementation of BaseForm's abstract method
    }
}

Notice the attribute on the BaseForm class. Then you just have to declare the TypeDescriptionProvider and two middle classes, but don't worry, they are invisible and irrelevant for the developer of Form1. The first one implements the abstract members (and makes the base class non abstract). The second one is empty - it's just required for the VS form designer to work. Then you assign the second middle class to the TypeDescriptionProvider of BaseForm. No conditional compilation.

I was having two more problems:

• Problem 1: After changing Form1 in designer (or some code) it was giving the error again (when trying to open it in designer again).
• Problem 2: BaseForm's controls was placed incorrectly when the Form1's size was changed in designer and the form was closed and reopened again in the form designer.

The first problem (you may not have it because it's something that haunts me in my project in few another places and usually produces a "Can't convert type X to type X" exception). I solved it in the TypeDescriptionProvider by comparing the type names (FullName) instead of comparing the types (see below).

The second problem. I don't really know why the base form's controls are not designable in Form1 class and their positions are lost after resize, but I've worked it around (not a nice solution - if you know any better, please write). I just manually move the BaseForm's buttons (which should be in bottom-right corner) to their correct positions in a method invoked asynchronously from Load event of the BaseForm: BeginInvoke(new Action(CorrectLayout)); My base class has only the "OK" and "Cancel" buttons, so the case is simple.

class BaseFormMiddle1 : BaseForm
{
    protected BaseFormMiddle1()
    {
    }

    public override void SomeAbstractMethod()
    {
        throw new NotImplementedException();  // this method will never be called in design mode anyway
    }
}


class BaseFormMiddle2 : BaseFormMiddle1  // empty class, just to make the VS designer working
{
}

And here you have the slightly modified version of TypeDescriptionProvider:

public class AbstractControlDescriptionProvider<TAbstract, TBase> : TypeDescriptionProvider
{
    public AbstractControlDescriptionProvider()
        : base(TypeDescriptor.GetProvider(typeof(TAbstract)))
    {
    }

    public override Type GetReflectionType(Type objectType, object instance)
    {
        if (objectType.FullName == typeof(TAbstract).FullName)  // corrected condition here (original condition was incorrectly giving false in my case sometimes)
            return typeof(TBase);

        return base.GetReflectionType(objectType, instance);
    }

    public override object CreateInstance(IServiceProvider provider, Type objectType, Type[] argTypes, object[] args)
    {
        if (objectType.FullName == typeof(TAbstract).FullName)  // corrected condition here (original condition was incorrectly giving false in my case sometimes)
            objectType = typeof(TBase);

        return base.CreateInstance(provider, objectType, argTypes, args);
    }
}

And that's it!

You don't have to explain anything to the future developers of forms based on your BaseForm and they don't have to do any tricks to design their forms! I think it's the most clean solution it can be (except for the controls repositioning).

One more tip:

If for some reason the designer still refuses to work for you, you can always do the simple trick of changing the public class Form1 : BaseForm to public class Form1 : BaseFormMiddle1 (or BaseFormMiddle2) in the code file, editing it in the VS form designer and then changing it back again. I prefer this trick over the conditional compilation because it's less likely to forget and release the wrong version.

Solution 5

I had a similar problem but found a way to refactor things to use an interface in place of an abstract base class:

interface Base {....}

public class MyUserControl<T> : UserControl, Base
     where T : /constraint/
{ ... }

This may not be applicable to every situation, but when possible it results in a cleaner solution than conditional compilation.

View more solutions

Comments

[Oliver Friedrich]

pity, but thats how it is done yet. Hoped of a correct way to do this.

[Allen Rice]

There is a better way, see Smelch's answer

[nos]

Do your form and the abstract base class have a no-arg constructor ? Cause that's all we had to add to get the designer working to show a form that inherited from an abstract form.

[neminem]

Worked great! I figure I'll just make the modifications I needed to to the various classes implementing the abstract one, then remove the temp middle class again, and if I ever need to make more modifications later, I can add it back. The workaround did, indeed, work. Thanks!

[RB Davidson]

Your solution works great. I just can't believe Visual Studio requires you to jump through such hoops to do something so common.

[Arvin]

May I also suggest to wrap MiddleClass.cs on an #else

[Stéphane Gourichon]

This did not work for me. Visual Studio designer ended up complaining about properties that my particular AbstractControl class implemented but UserControl didn't.

[Alex Wiese]

What is wrong with doing this instead #if DEBUG public class BaseForm : Form #else public abstract class BaseForm : Form #endif

[Adrian Botor]

This did also work for me that i am using CF 3.5 there is no TypeDescriptionProvider

[Sukasa]

You need to import System.ComponentModel. This worked great for me, thanks!

[kad81]

@alexw because if you did that, you couldn't use any abstract methods or properties in the base class (would fail to compile when in debug mode).

[RobC]

Couldn't get this to work in VS 2010, though smelch's did work. Anyone know why?

[Oblivious Sage]

@RobC Designer is kind of grumpy for some reason. I found that after implementing this fix I had to clean the solution, close & re-launch VS2010, and rebuild; then it would let me design the subclass.

[Oblivious Sage]

It's worth noting that because this fix substitutes an instance of the base class for the abstract class, visual elements added in the Designer for the abstract class will not be available when designing the subclasses.

[InteXX]

This worked for me, but I first had to restart VS 2013 after building the project. @ObliviousSage - Thanks for the heads-up; in my current case at least this isn't an issue but still it's a good one to watch out for.

[InteXX]

Could you provide a little more complete code sample? I'm trying to understand your design better and I also will be translating it to VB. Thanks.

[Luke Merrett]

This solved the issue I was having with Juan's solution in VS 2013; on restarting VS the controls load consistently now.

[Shaun Rowan]

This is what I went with. I just threw NotImplementedException in the base class to make the error obvious if it's forgotten.

[Joshua Pech]

Should this be calling base(TypeDescriptor.GetProvider(typeof(TAbstract))) or base(TypeDescriptor.GetProvider(typeof(TBase)))? I've seen examples of both.

[Daniel Bonetti]

Do I need to put the abstract methods in the AbstractControl, right? So if I inherit the BaseForm doing public class BaseForm : AbstractControl I will need to implement the abstract methods in the BaseForm and then override in the Form1. Am I doing it right?

[Mystic Lin]

@ObliviousSage Clean, close , reopen, close all tabs, and rebuild. It worked in VS2010!! Thank you a lot.

[Mystic Lin]

It worked for me after reopening VS2010. This is the best TypeDescriptionProvider sample in what I searched.

[Davide Andrea]

@juan-carlos-diaz Please add "using System.ComponentModel;" to your answer

[Chris]

Worked for me in VS 2017 seemingly without the appsettings part even.

[Darius]

But if I use a middleClass which is not an abstract class, then whoever inherits the middleClass does not have to implement the abstract method any more, this defeats the very purpose of using abstract class in the first place... How to resolve this?

[ti034]

@Darius, I agree. I am required to implement the abstract methods in the middle class, which defeats the point. I've tried jucardi's answer, but I cannot see the base form controls on the inherited form.

[ti034]

@MysticLin, I tried your rebuild suggestion but am still not seeing the base form controls in my inherited form (in the designer). Using VS 2017. Any one else try this recently?

[Darius]

@ti034 I couldn't find any workaround. So I just make the supposedly abstract functions from the middleClass have some default values that can easily remind me to override them, without having the compiler to throw error. For example, if the supposedly abstract method is to return the title of the page, then I will make it return a string "Please change the title".

[chanban]

I know this is old but I found this was the least hacky solution. Since I still wanted my interface tied to the UserControl, I added a UserControl property to the interface and referenced that whenever I needed to directly access it. In my interface implementations, I extend UserControl and set the UserControl property to this

[mjr]

didn't want to hassle with the accepted solution, and this worked perfectly. had to clean and rebuild as noted by @ObliviousSage