Take the 2-minute tour ×

Curious situation:

public class MyTextBox : TextBox
    // I want use the same height for all MyTextBoxes
    public new static int Height;

public Form1()

    MyTextBox mtb1 = new MyTextBox();
    MyTextBox mtb2 = new MyTextBox();

    mtb1.Multiline = true;
    mtb2.Multiline = true;

    mtb1.Location = new Point(50, 100);
    mtb2.Location = new Point(200, 100);

    mtb1.Size = new Size(50, 50);
    mtb2.Size = new Size(150, 150);


    mtb1.Text = mtb1.Height;
    mtb2.Text = mtb2.Height;
    // Error 1 Member 'WindowsFormsApplication9.MyTextBox.Height'
    // cannot be accessed with an instance reference;
    // qualify it with a type name instead

The same thing in VB.NET

Public Class MyTextBox
    Inherits TextBox
    Public Shared Shadows Height As Integer
End Class

mtb1.Text = mtb1.Height ' Text will be "0" '
'Warning 1   Access of shared member, constant member, enum member or nested '
' type through an instance; qualifying expression will not be evaluated.



  1. Couldn't this method be used to hide the public members in the inherited classes? Sometimes this can be useful...
  2. How can I use same Height for all members?
share|improve this question
I ask also how to use common/static/shared height for textboxes –  serhio Feb 3 '10 at 10:31
add comment

1 Answer

up vote 1 down vote accepted

When would it be useful? I really don't think it's a good idea to hide members in this way. It's just going to cause a maintenance nightmare - when you see "Height" you can't easily tell which member it's really referring to.

IMO, "new" should only be used as a last act of desperation, usually if a base class has introduced a member which clashes with one of your existing ones. It shouldn't be used as a way of deliberately avoiding normal OO design principles.

share|improve this answer
ok, what about the same height for all textboxes? Or I should rename the field? –  serhio Feb 3 '10 at 10:33
@serhio: Definitely rename the field - if indeed you need a field in the first place. –  Jon Skeet Feb 3 '10 at 10:37
@Jon Skeet: What if the base class provides a protected member which should not be made available to descendants of a particular derived class (e.g. MemberwiseClone)? It would seem better to hide the protected member by shadowing it with something that should obviously not be used (e.g. an WriteOnly property of an enumeration type DontTryThis whose only defined value is DontTryThis.NoReallyDont) than leave it available allow it to be wrongfully called. A keyword specifically to simply hide the inherited method might be nicer, but I don't know of one in vb.net or C#. –  supercat Dec 2 '10 at 21:28
@supercat: If the base class provides a protected member, that should be visible to all derived classes. Otherwise it's breaking Liskov's Substitution Principle. Basically it's poor design - don't put a sticking plaster over it with "new". –  Jon Skeet Dec 2 '10 at 21:31
@Jon Skeet: The LSP is important for public members of a class because a derived class 'foo' which derives from 'bar' might be passed to some code that expects a 'bar'. If a 'foo' could not be used in place of a 'bar', such code would break. Such polymorphism isn't an issue with protected methods. If class 'foo' inherits from 'bar', the base of a foo object will be a 'bar'. Period. There's no way some other class will be inherited from 'bar' and somehow become the base of foo. The fact that bases cannot be substituted is a big part of the reason for having protected members in the first place. –  supercat Dec 2 '10 at 23:48
show 14 more comments

Your Answer


