Question on Inheriting Controls

  • Thread starter Thread starter David White
  • Start date Start date
D

David White

I have a project which is a Windows Form "Wizard". Each "page" displayed in the
main Wizard form will be a user control. Each of these user controls will share
many similar attributes. So it seems natural for me to create a base user
control class and have all my "pages" inherit from it. But it seems that VS2005
really isn't happy doing this unless the base class is compiled and put into an
assembly other than the one containing my project. The visual designer get al
hosed up and complains. I can force it all to work by hand-coding some changes
but this seems way harder than it should be. Is there something I am missing
here? Thanks.
 
We're still on VS2003 here, but I've seen the same effect.

The problem is that in order to design a control, the Designer starts
by instantiating its base class and then lets you draw on that.

If the current .cs won't compile, the Designer understands that: it
still lets you design, and it preserves any controls that you've placed
on forms, even though it can't "see" those controls at the moment
because it doesn't have a compiled assembly from which to work.
However, if the assembly containing the base class is missing, then the
Designer does something truly awful: it just regens the code for your
Form _without_ the derived controls. They just kind of vanish off the
form. I guess the Designer says, "Hey, these controls are based on a
class I can't find. I don't know how to generate code for them, so I
won't."

So, it's not just "in the same assembly." It's "base class assembly is
missing," which it would be if it's the current assembly and the
current assembly won't compile (which is normal during development).

So, you're not alone. Don't know what to do about it, though, other
than put the base class in another assembly.
 
Back
Top