Subclassing Third Party Frameworks...
Subclassing is the easy part, keeping all the designer functionality is gonna to be the time consuming part. The reason is because in order to keep all the designer functionality you'll have to go back in fill in all the appropriate attributes for any code you extend or override.
My recommendation is to use the controls as is - in other words don't create a subclass of every MM.NET control "right off the bat". If later you feel you need to add a superclass in between your class and an MM.NET Class you can simply do so by changing your code. It's not like in VFP where you had to hack the table and add code like superclass::mymethod(). .NET is a lot more practical when it comes to changing a superclass.
Besides, that's what frameworks like MM.NET are for... Let Kevin worry about the features. Go on! Have fun working on the FUNdemental part of your project. Stop worrying about what features you'll want to add to the framework. :)
In the 8 years that I've been working with Kevin's frameworks I've never had to subclass *ALL* his classes... In fact, the occassion was rare.
My recommendation is to use the controls as is - in other words don't create a subclass of every MM.NET control "right off the bat". If later you feel you need to add a superclass in between your class and an MM.NET Class you can simply do so by changing your code. It's not like in VFP where you had to hack the table and add code like superclass::mymethod(). .NET is a lot more practical when it comes to changing a superclass.
Besides, that's what frameworks like MM.NET are for... Let Kevin worry about the features. Go on! Have fun working on the FUNdemental part of your project. Stop worrying about what features you'll want to add to the framework. :)
In the 8 years that I've been working with Kevin's frameworks I've never had to subclass *ALL* his classes... In fact, the occassion was rare.
posted by Victor Campos | 2:18 PM
0 Comments:
Post a Comment
<< Home