Can you use abstract UserControls?

I created a UserControl called Dad. Marked it as abstract. I created a class Son and changed it to:

public class Son : Dad

{

public Son() : base()

}

If I 'View Designer' on Son it fails witha message saying ...

The Designer must create an instance of type 'Windows.Application1.Dad' but it cannot as the type is declared as abstract.

Is this just a weakness in the IDE?

We have two points to contend with-

a/We dont want to use abstract controls since we cant design them.So,we need a non-abstract class with virtual methods to enable overriding.

b/to enforce overriding,throw a custom exception in each of the virtual methods saying that this method needs to be overriden.Will this suit your scenario?

Yes, the Designer cannot currently handle abstract or generic UserControls.

The same applies to abstract forms as well.When you open VS.net the form designer is shown,since the Form derives from System.Forms.Form and the designer of the base class is used.When you try to use an abstract form,an instance cannot be created and hence the designer of the abstract Form cannot be used by derived classes.

You are able to work around this in Visual Studio 2005, however, it is a little work.

Brian Pepin has blogged on this: http://www.urbanpotato.net/Default.aspx/document/2001.

Hi David,

I was aware of this workaround but presumed that VS.Net 2003 is being used.

Thank you all gentlemen for your replies. The Urban Potato shows this was not such a trivial question. My prime reason for wanting this was to enforce a series of abstract methods on derived UserControls. I decided on a kludge as I did not really understand the UP answer.

I created three classes

public partial class Dad : UserControl {public Dad() { }}}

public abstract class DadAbstract : Dad

{ public abstract void MustImplement(); }

class Son : DadAbstract {

public override void MustImplement() {}

public Son() : base( )

{ InitializeComponent( ); } ... all control stuff ...}.

DadAbstract contains abstract void MustImplement();

Son contains public override void MustImplement() { /* code */ }

Even though Son does not compile because of the overrideI can still 'View Designer' and add controls. I then leave the designer and change 'class Son : Dad' to 'class Son : DadAbstract'. This action is (luckily) enforced as it is needed to make Son compile.

Everything then works as the problem is in the IDE rather than .Net. If I need to change theSon controls then all I have to do is change Sonback to derive from Dad rather than DadAbstract, do my designer changes then return to Son : DadAbstract.

If you disagree (particularly with the italicised portion) then please put me straight.

Whoops - code sample should have shown Son deriving from Dad rather than DadAbstract

The solution is that your user control can implement an interface instead of an abstract class(if it suits your design) OR if your user control provides some base implementation for some methods which derived user controls will use,then make the abstract methods as virtual and empty and override them in your derived controls.

I wanted to enforce the requirements. The Virtual and Interface methods both depend on the derived class 'noticing' they have to implement the inteface or override the methods.

I am relatively new to C# and was trying to find some other way. It takes a long time when you don't really understand what you are doing.

I tried to find a [Designtime] attribute so the IDE would see it as concrete but it would be abstract at run time. No joy.

Maybe (I thought) I can add an Interface to the superclass and somhow say that it need onlybe implemented by derived classes - couldn't find that one either.

Thanks for your reply - Paul Cotter

We have two points to contend with-

a/We dont want to use abstract controls since we cant design them.So,we need a non-abstract class with virtual methods to enable overriding.

b/to enforce overriding,throw a custom exception in each of the virtual methods saying that this method needs to be overriden.Will this suit your scenario?

I have done that now.

<excuse>

I am fairly new here and from a powerbuilder background. The PB inheritance model and the code 'compartmentalisation' are easier to understand there - although that leads to less flexibility. The .Net classes are huge, entirely flexible but that leads to a large learning curve. (possibly kerb or curb are more appropriate)

Thank heavens for Intellisense and 'background compile as you code'

</excuse>

...and thanks for the replies

Can you kindly mark the post as an answer if it helps you?

What about generic Dad?How can we manage this situation?:

You can wrap the generic for each type you want to work in the designer:

public partial class DadString : Dad<string>

And then DadString can be used in the designer just fine. Not ideal , but I have found it handy for most purposes.