abstract base class for form

[Brad Williams]

If I create an abstract class derived from Form, from which I can derive my
actual forms, this works ... except designer support gets broken.
Initiating the designer for the derived form/class causes the designer to
try to instantiate the base class -- which can't be done because that base
class is abstract.

Why does the designer need to instantiate the base of the form I am trying
to open?

Thanks,
Brad Williams

 

[Herfried K. Wagner [MVP]]

If I create an abstract class derived from Form, from which I can derive my
actual forms, this works ... except designer support gets broken.
Initiating the designer for the derived form/class causes the designer to
try to instantiate the base class -- which can't be done because that base
class is abstract.

Why does the designer need to instantiate the base of the form I am trying
to open?

.... to show the form in the form designer.

 

[Brad Williams]

Why isn't instantiating the class of the form sufficient? What does
instantiating the base class have to do with showing the form of the derived
class in design mode?

 

[Bob Powell [MVP]]

The designer must instantiate an object of that same class because you may
have added properties to your class that you would expect to be exposed at
design time.

Abstract Form base classes are just a no-no. It's like the rules about which
side of the road you drive on. You don't go driving down the wrong side of
the road do you? You can if you want to but it usually becomes painful after
a while...

--
Bob Powell [MVP]
Visual C#, System.Drawing

Check out February's edition of Well Formed.
Non-client drawing, Graphics Transform stack and Flood-Filling
http://www.bobpowell.net/currentissue.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/gdiplus_faq.htm

Read my Blog at http://bobpowelldotnet.blogspot.com

Why isn't instantiating the class of the form sufficient? What does
instantiating the base class have to do with showing the form of the derived
class in design mode?


derive

 

[Jon Skeet [C# MVP]]

The designer must instantiate an object of that same class because you may
have added properties to your class that you would expect to be exposed at
design time.

But those would still be exposed by the derived class, wouldn't they?
Like the OP, I can't see any reason why the abstract class itself would
need to be directly instantiated. An instance of the derived class
should do just fine.

(As an example, MarshallByRefObject is abstract, and yet the forms
designer creates instances of that indirectly, as every control
inherits from it...)

Abstract Form base classes are just a no-no. It's like the rules about which
side of the road you drive on. You don't go driving down the wrong side of
the road do you? You can if you want to but it usually becomes painful after
a while...

Sure, but I think the OP was asking *why*, given that there doesn't
seem to be any reason for creating an instance of just the abstract
class rather than the actual specified class.

 

[Ying-Shen Yu[MSFT]]

Hi,

IMHO, one reason why we can't instantiate the actual specified class is in
design-time the derived class is usually being modified, we can not
instantiate it since there is no executable code for it. So winform
designer using code serialization ( see InitializeComponent )to workaround
this problem.

Just my understanding.

Best regards,

Ying-Shen Yu [MSFT]
Microsoft community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.

 

[Brad Williams]

So maybe the designer instantiates the base class, then uses reflection and
"code serialization" to read and execute the derived class's existing
InitializeComponent code in order to set run-time properties on that base
class instance. Seems plausible to me.

Thank you for your response.

Brad Williams

 

[Jon Skeet [C# MVP]]

So maybe the designer instantiates the base class, then uses reflection and
"code serialization" to read and execute the derived class's existing
InitializeComponent code in order to set run-time properties on that base
class instance. Seems plausible to me.

Doesn't sound very plausible to me, because the base class may well not
*have* all of the properties of the derived class.

Then again, maybe this is why I'm constantly frustrated by the forms
designer...

 

[Ying-Shen Yu[MSFT]]

Hi,

Actually, the properties, events, attributes defined in the derived form
class will not be available in design-time. The same thing is true for
other root component designer scenarios(the designer view of UserControl,
Component etc).

Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.