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?
Best Answer
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 anabstract
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
Problem
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:
public **abstract** class MarshalByRefObject
)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
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
MiddleClass.cs
BaseForm.cs
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.