Visual Studio and abstract base forms
The inability to cope with abstract forms is probably my single biggest gripe about Visual Studio.
When I am building a reasonably-sized application I - like most sane developers - build a forms framework; basically a hierarchy of forms that abstract certain services and functionality. An extremely useful device is the ability to define abstract methods and properties on base forms. That way, when you derive a new form from one of these base forms, your code will not compile until you implement all the abstract members. Now, that is a real time saver because
- You can easily see exactly what code is needed by your framework; no time wasted trawling through the inheritance hierarchy - just compile and see what the compiler complains about.
- No time wasted running up the project and getting to the right form, only to have a handy NotImplementedException thrown at you. You can’t not implement an abstract method as it won’t build in the first place.
- Finally, and perhaps most importantly, you reduce the time you spend fixing bugs that result from missing functionality.
For years I’ve developed Win32 forms-based apps in Delphi, and it’s designer handles abstract base forms without a flinch. However, Visual Studio - which in many ways is an amazing piece of software - just cannot do it…not even Visual Studio 2005! You can create and work with an abstract form - no problem. However, you cannot derive from one, which, to put it mildly, is less than useful.
The reason is that, when you open a form in the designer, Visual Studio does not instantiate the form class. Rather, it instantiates the base class of the form and then it parses the InitalizeComponent method of the derived class so it can apply the necessary modifications. For more detailed info see Raghavendra Prabhu’s explanation
I’m sure the windows forms designer was written by some extremely clever people. So it amazes me that it has this limitation. You can’t just say “Sorry, you can’t have abstract base forms because of the way we designed the designer”. I regard this as a bug and it needs to be fixed. Visual Studio “Orcas” is supposed to be getting “new UI tools and designers” - hopefully in amongst all the Avalon and XAML work someone will fix the design of the Windows Forms designer.
June 7th, 2005 at 19:35
Anyone know if this is fixed in VS.NET 2005? I don’t have an install handy, or I’d try it right now…
June 8th, 2005 at 11:35
Unfortunately, this is still a problem in Visual Studio 2005. I was actually using VS 2005 Beta 2 when I hit this problem and got so annoyed I had to blog about it.
As an aside, I first came across this problem in VS 2003 in an ASP.NET project. If I inherited my web forms from abstract base classes (which in turn inherited from System.Web.UI.Page) then I could not view them at design time - the designer threw it’s abstract toys out of it’s cot. I can however, get a simple web form to work using an abstract base - although depending on the order in which you do things you can get some weird problems. For example, after inheriting from the abstract base class I dropped a button on the form and double-clicked it it would generate a client-side javascript event hander. Although I had dropped a System.Web.UI.WebControls.Button on the form I ended up with an HtmlButton. And I couldn’t even set it to run as a server control.
The good news is that I can’t seem to reproduce these problems in a VS 2005 ASP.NET project. This is not surprising seeing as ASP.NET has had such a major overhaul since VS 2003.
So that just leaves WinForms. I hope the WinForms team realizes that this funtionality is important to some of us.
October 15th, 2007 at 21:43
Even VS2008 beta2 can’t do it, what a shame!