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.
The inherited form will definitiely inherit all the functionality that is public, won't it?
Now ... event handlers for the controls mostly buttons are also inherited?
I tried building the similar app as you demonstrated. I succeeded in inheriting the form.
I have two forms
Both contain (The inherited will definitely..) One text box & one button
Initially I had coded parent display button to display text "You clicked display" in textbox. But after modifying I changed the code like follows
publicpartialclass ParentForm : Form
privatevoid btnDisplay_Click(object sender, EventArgs e)
InheritedForm form = new InheritedForm();
You are creating an instance of InheritedForm in ParentForm. Now you do have an hen-and-egg problem, don't you? Both event handlers btnDisplay_Click are handled if you create an instance of InheritedForm and thus the text will be displayed in the hidden form, when the new instance pops up. Just remove the btnDisplay_Click handler in ParentForm and instantiate and show InheritedForm.
You must not create an instance of an inherited form in its base form (of course you can, but I have no idea why you would?), because by deriving from ParentForm you are instantiating InheritedForm. ParentForm I understand as a template for other forms, so create an instance of InheritedForm in your MainForm, which is now using ParentForm with its controls as its base and btnDisplay will work as expected (I think ).
Application engineer for Measurement Software
Wow .. now that was something that my dumb brain did not strike. Ya by doing that I am voilating OO principle of inheritance.
But, as a matter of factly it was just a test. Anyways. So it does have solution then. Fine.
When you select a control or component in the designer view, the properties window has a section named "Design". "GenerateMember" and "Modifiers" are two of the properties in that section. The latter can be used to change the visibility (private, protected, etc.) of the selected control or component, so you don't have to change the code by hand.