I am just now struggling with inherited forms. Normally this works, but sometimes the designers brings
unpredictable results. The designer just f**ks up the inherited forms. Nothing is mentioned in this article that this does only work 90% . Like I said, sometimes it works. Sometimes the designers messes up everything. Sure it is a problem of the lousy Visual Studio Designer. It's not a problem of the code.
But it is a very dangerous thing. In my application I have hundreds of inherited forms. Only some (10%) are running crazy in the designer, also there is no real difference with the running ones.
Inheriting forms is a very important feature for me. The problem is: It does not work properly in VS 2008.
The problem is: You are promoting here a technology, which seems to work fine in a simple example.
But: Live is not so simple. People use this technology and sure they use them in large projects. People work for weeks on one solution and suddendly the thing crashes. Sure ist is not your responsibility that the technology does not work properly on 2008. It is the responsibility of Microsoft. They changed a lot in the designer, and not for good.
I red your article some time ago, searching how to inherit forms. It worked. So I built my application on this theory. And it worked. (Most of the times). Unfotunatelly most of the times is not good enough at all. Now I end up replacing this inheritage with different technologies. In my case inheritance of forms turned out to be the wrong way. I have to rework 180 forms. (because of the VS designer)
So a warning, that this technology should be handled with care would be appropiate. A warning that the designer could fail should be mentioned. Inheritance does not work properly in VS 2008
This is why the 1. The article could lead programmers like me into a trap
Right i see your problem, however again its not my fault -
Instead of voting 1 for the article, the correct response is to write an article of your own based on your experiences including any mechanisms you might have learn on how to overcome issues you encountered.
Especially now as your vote of 1 has been removed. The best way to inform people is to write a follow up article.
Not to punish the original article writer for something that is not his fault.
I wish you luck in fixing your problems, its never fun when these things happen.
To paraphrase Fred Dagg - the views expressed in this post are bloody good ones.
I was so "lucky" as to try my first example using a TableLayoutPanel control to inherit in a derived form. Note that this kind of container control can not be set to protected in order to be manipulated in an inherited form...
PS: The video tutorial is excellent. I hope this becomes a common practice to every article. Well done!
Good article at a good moment. I just posted this article and was wondering if you could help me?
i have a base class inherited from a usercontrol. This base class contains a imagelist with 12 bitmaps and a datagrid, build in designtime.
Now i created 10 new classes inherited from my base class and weird as it is. the image list is copied and not inherited. changing the bitmaps in the base class doesn't change the ones in the other 10 inherited classes..
result is that i have to modify it for each of the classes. Another bad thing is that each class has his own resource file containing the bitmaps. so 75kb x 10 = 750kb. i suppose this is no inheritance like i known it in Delphi, this is copying source.
Is there a way prevent copying the bitmaps but actually inheriting?
Reading you're article i suppose i could solve this by making the imagelist private. At this moment it's protected.