Ok, when I first read about visual inheritance I almost started drooling.  I've been mimicking this behavior for years with controls that I would include on the "inherited forms".  I've only just inherited my first form today so nothing fancy yet.  I'd like to start a discussion of happy stories, war stories, issues you've run into, etc. so that we all may learn how to properly utilize this delightful feature.

two things off the top of my head

you can't make your base form MustInherit (or abstract) because then the WindowsForms Designer can't open up the inherited form.  by no means a show stopper, just a pisser for we perfectionists  ;) 

can't say i've really had any trouble other than that, it's great!

dang, that's only one thing...i lost my train of thought and now it's gone  :p  I'll post it later if i can think of it...but yah, good stuff!

There are a couple of "gotchas" that I'm aware of.  First, stay away from adding a list box to your base form with some items, and then try to add more items in your derived form.  The visual inheritance feature can only tell the difference between an inherited object and a non-inherited object if that object implements the IComponent interface.  Since most stuff you shove into a list box isn't an IComponent, Visual Inheritance will get confused and add your items twice.

I would also stay away from adding a basic menu to your base class and then beefing it up in your derived class.  Tempting, yes, but in my experience it's been a bit of a bug farm.

Thanks for those items.  I already knew about the visual inheritance thing, damn me and my object oriented tendencies in an object oriented language...

In any case, the only thing I've come accross aside from mentioned things is how annoying it is to get layout to work the way you want it to.  Maybe it is just me but it's annoying having to put everything in panels and docking the panels when you want them to stay put.

<quote>
Maybe it is just me but it's annoying having to put everything in panels and docking the panels when you want them to stay put.
</quote>

stay put?  what exactly do you mean?

Ok, let's take a simple example ... the super form is going to have a common set of buttons on the bottom, while the sub forms are going to provide the content.  The sub forms can be any size and will be defined by the sub form designer.   When you place buttons on the super form, unless you put them in a panel and dock it to the bottom, they will be positioned exactly (X, Y coordinates) where they are on the super form.  When I first did this I was like "Oh, I'll just set the anchor tags to bottom-right" ... no luck, it anchors them after the sub form is created, so they are anchored but in their original positions.

I thought the exact same thing the first time I did that too.  Put some code in the SizeChanged Event to move them where you want to in your base form and it'll work.

Hey-

So, I'm a writer on the Windows Forms User Education team, and I would be remiss in my duties if I didn't provide links to the inheritance docs in MSDN.

The portal topic, with links to all of the task topics is "Windows Forms Inheritance", available online at:

<a href="http://msdn.microsoft.com/library/?url=/library/en-us/vbcon/html/vbconFormInheritance.asp?frame=true">http://msdn.microsoft.com/library/?url=/library/en-us/vbcon/html/vbconFormInheritance.asp?frame=true</a>

and in MSDN (if you have MSDN installed locally on your machine):

ms-help://MS.VSCC/MS.MSDNVS/vbcon/html/vbconFormInheritance.htm

You will notice that the coverage of Visual Inheritance is pretty slim; there is a walkthrough ("Walkthrough: Demonstrating Visual Inheritance ") to help first-time users unacquainted with employing visual inheritance in their applications.

Having said that, are there inheritance-related docs you would like to see in MSDN?

Thanks
Seth 

Maybe an article that creates a base form for data entry that could then be inherited from to create different types of entry forms.  Or maybe demonstrate how to setup some standard templates to use throughout your projects, like if you want an explorer-style app, etc.  These are all things I've done quite a few times and I'm sure it would be helpful for someone who's never done it before.

I guess just some sorta of real world example would be good.

Yea, I've read though the <sarcasm>thorough</sarcasm> docs in MSDN and it was that which inspired me to start this thread.  Personally I'd like to see docs/samples on:

1.  "Best practices" on solving this layout problem me and HumanCompiler have been discussing.
2.  Details on how it the designer handles it, for example, explain away the list items issue that was mentioned above.
3.  More complex samples with multi-level inheritance, or just more than one control ;)
4.  Just more in general, I feel this to be a very, very powerful aspect of Windows Forms, and MSDN's negligance isn't very welcoming to new users.

Thanks for the feedback!

I'll open bugs for this material, and see what I can do about getting it included in future doc plans.

Seth

Actually the layout issue is a killer.

I have a base form that handles all data entry requirements (insert, delete, update, select - usual CRUD).  The derived form just needs to change the dc, da, ds by reference.  

The base form has a panel that contains a tab control.  The first tab page contains a grid within a panel and the bottom of the page has a panel with command buttons.  The second tab page contains a panel with the actual controls and a bottom-docked panel with commands.  

My problem is that the derived form cannot move to the second tab page so that I can add controls to it.  I have tried making all controls on the form protected and even public.  

I too was excited by visual inheritance - it allowed the local business analyst / vb developer to rapidly develop forms while focusing on the business logic and end-user requirements.  If we are relegated to cut & paste coding for basic data entry forms then we might as well begin working off-shore.

I would be happy to discuss and share these examples with Microsoft and work to a shared solution with others.

Phil

We are aware of some of the layout problems, and we have been working on a solution.  Most of the layout issues come from the fact that the base and derived forms have to both add controls to the form's Controls collection.  If you need to move things around so that you have a derived control in between two private base class controls, there's no way to generate that in source code so it falls apart.  We're changing code gen a bit so that we'll be able to directly set the index of a control in the collection, which should offer you much better support for controling layout in derived forms.

My savior! I just had this problem the other day and had to change my idea around quite a bit (unfortunately having to avoid Visual Inheritance for some aspects).  So, this can be expected in Whidbey, or beyond?

The features Brian mentioned will be available in a future release.  ;)

 - mike

I'm having a similar inheritance issue.  I created a super user control which has a panel docked at the top with a label for the page title.  Once I inherit this control and add another panel docked at the top then the added panel docks above the inherited panel (which of course I want to be at the top giving the page title).

I tried making the panel private but that did not work.

Best I can tell, the order that an item is added to a class is the order it is docked.  I've  proven this several times in several scenarios.  Since the inherited panel is not added to the page it is not docked first.  The items added to the page are docked first.

Any ideas on how to keep the inherited panel docked topmost?

Thanks!