All was going well until I tried to open the designer window for a user control that inherits from an abstract (MustInherit) class.  The designer won't open because it's trying to instantiate the base class, for whatever reason.  Is there a way around this, is this by design or a bug, is it better in C# or .NET v1.1?

I guess I can work around it by removing the MustInherit/MustOverride keywords before opening the designer and then putting them back, but what a pain, and am I asking for trouble in some other area?

And the first demo is Monday...

Thanks,

John

that is not a bug.  honestly, i think it really stinks, but according to some people at MS, it would be a really big deal to change and basically a big workaround for just a piece of mind, so it doesn't sound like it'll ever get changed.  It's nothing that is language or version specific.

A fellow MVP has a workaround for it, but I don't think he frequents the forums.  Maybe I'll see if I can round him up!  ;) 

Yup, based on the architecture of how the designer interacts and displays classes, this is a design issue rather than a bug.  Specifically, in order to display items in the designer, the designer must first instantiate those items.  So, when you are dragging a textbox on a form, the designer creates an actual instance of the textbox.  In the case of a UserControl or a Form, however, the designer must instantiate the base version for display as, by designing, you are modifying he class definition.  Thus, it tries to instantiate the "MustInherit" form.  To workaround this, you need to make your base form declaration and signatures look like this:

 #If DEBUG Then
 Public Class MyForm
 #Else
 Public MustInherit Class MyForm
 #End If

 ...

 #If DEBUG Then
   Public Overridable Sub Foo()
     Throw New NotImplementedException()
   End Sub
 #Else
   Public MustOverride Sub Foo()
 #End If

 End Class

Therefore, you will be able to display the derived form in the designer when in Debug mode.  However, once you switch to release mode, you will not be able to display the derived form in the designer.

Hope this helps.

Incidently the core reason for this is most likely the reason why the WinForms designer is so horribly slow with anything but small forms...

So yes, MS should look into re-writting it because there is more than this one little anoyance that results from it.

I've had enough of forms taking 45-60 seconds to load in the designer but loading in 2 seconds when you run the project to last me a life time. If I added up all of those seconds, I would have days back!

Or you could go back to VB6 or C++ and lose even more days!  ;)  Just be patient...it's better than what we all used to use!  :) 

Thanks, all.  I'll work around it for the time being.

John