Deriving from a Form class in .NET

Question

Theoretically you can derive from a Form but is it something you should not do? I intuitively think so but I've never heard of any rule like this.

Edit: of course I meant some conrete class that already derives from Form. For example if I've got class MyForm : Form, the question is can i derive from MyForm?

Answer 1

There's no hard and fast rule that prevents you from deriving a windows Form. If you have a good reason to do it (e.g., bolting in some features common throughout your project throughout all forms), then go ahead.

Answer 2

You should derive from Form when creating a new Windows Form. When creating a new form in Visual Studio, the source files you get already derive from Form.

Answer 3

The question really depends on what your derived class does.

Form and many such end classes are designed to do lots of complex tasks to give you full advantages of form related activities without having to code too much.

The rule would be something like this, "If you intend to do a simple window operation, and if it may not disturb the regular behavior then its better not to derive from form.

Or since form is heavily loaded, you can save memory and cpu time by deriving it from base classes instead of form.

Answer 4

It's perfectly reasonable to derive forms from a common base Form-derived class, and can be useful for having a standard look and feel for your application.

Answer 5

We've had success deriving a class from form and then deriving all of our forms in the project from it. It allows us to easily apply project-wide policies. All of our forms have a consistent look and feel. It also made it easy to have each form remember its size and location.

Answer 6

I highly recommend inheriting from a BaseForm. This makes it very easy to f.e. make all EditForms look a like, because you can set the common controls on the base (like buttons), give them a backcolor/image, etc. Same goes for all sort of forms that can be grouped. I usually have 1 BaseForm and then again a BaseForm according to it's 'group' (edit, list, dialog, ...)

It makes you winapp look more consistent.

Same goes for code, usually Edit form have a similar code base: validation, save logic, ... You can put all this logic on the baseform(s) and then have a few abstract methods that you can implement on the childform.