1

I have a base winform and 2 derived winforms. The base winform contains labels, textboxes and a save button. Each derived class contains additional labels and textboxes. The SaveButton_Click event is calling to a Save method. I defined the Save method as abstract in the base class therefore I am also defining the base winform as abstract.

Here is my code:

public abstract partial class BaseRowInfo : Form
{
    public BaseRowInfo()
    {
        InitializeComponent();
    }

    private void SaveButton_Click(object sender, EventArgs e)
    {
        Save();
    }

    protected abstract void Save();
}

public partial class EditableRowInfoFrm : BaseRowInfo
{
    public EditableRowInfoFrm():base()
    {
        InitializeComponent();            
    }

    protected override void Save()
    {
        // TODO
    }
}

public partial class ReadOnlyRowInfoFrm : BaseRowInfo
{
    public ReadOnlyRowInfoFrm ():base()
    {
        InitializeComponent();            
    }

    protected override void Save()
    {
        // TODO
    }
}

Once I am defining the base class as abstract, I do not have anymore the ability to edit the UI of the derived forms. Does the fact that I am defining the Base Class as abstract is wrong? What is the solution in case it is acceptable to define it as abstract?

ehh
  • 3,412
  • 7
  • 43
  • 91

2 Answers2

1

No, there is nothing wrong with your approach. The Visual Studio IDE just doesn't like you for using abstract classes in the editor.

I can understand from Microsofts point-of-view this is very hard to implement. You risk changing something from the base class. I am not sure how they would implement a designer that would work in a decent way.

There are two options:

  • Write the UI code by hand for every deriving class;
  • Add a control, possibly implementing a common interface for communication, that you can add into your derived form. That control can be created using the designer.
Patrick Hofman
  • 153,850
  • 22
  • 249
  • 325
  • The first option will be painful. Can you please emphasize the second option, not really clear to me. Thanks – ehh Feb 08 '16 at 13:05
  • If you have a footer section for example where you need to put in some extra controls, you can put those in a control which you can add later on to the deriving class by code. That would minimize the need to manual code. – Patrick Hofman Feb 08 '16 at 13:05
  • It is more like, adding new buttons, textboxes, changing properties, colors, fonts and so on. I was expecting to do it while the form is displayed and not via code. It will require to run the application for each change to ensure this is the expected appearance I am looking for. – ehh Feb 08 '16 at 13:09
  • 1
    It is only the abstract-ness of the class that is a problem for the designer. It tries to create an *instance* of the class, and bombs when it cannot do so. So if you absolutely want to use the designer (I don't bother with it anymore, coding by hand is just as easy), about your only choice is to compromise your design. Make the class non-abstract and simply give it empty virtual methods. You can make it abstract again once you're done designing it. – Cody Gray - on strike Feb 08 '16 at 13:15
-1

If you want to be able to edit UI controls of the abstract class in the derived class mark those controls with 'protected' access modifier instead of 'private'.

Beniamin E.
  • 156
  • 7