ProductName hides System.Windows.Forms.Control.ProductName

Question

I have a property ProductName in my Form. I am getting warning while compiling the code.

FormInventory.ProductName hides inherited member 'System.Windows.Forms.Control.ProductName'. Use the new keyword if hiding was intended.

below is my code

public partial class FormInventory : Form, IInventoryView
{
   public FormInventory()
   {
   } 

   public string ProductName
   {
      get { return this.textProductName.text; }
      set { this.textProductName.text = value; }
   }
}

textProductName is a textbox.

I know that ProductName hides the base class's property Forms.Control.ProductName. My question is

Is it possible to suppress the warning without Renaming my FormInventory.ProductName property
I am currently in the beginning of the development, if i hide this property with the new modifier will there be any problem at the time of releasing the product, because base property Forms.Control.ProductName returns the product name of the assembly containing the control. Where as my FormInventory.ProductName returns a user entered value.
Where will we be using this Forms.Control.ProductName, because i have never used it before.

I have searched and found Similar questions

these questions doesn't solve my problem but helped me in understanding the cause for the warning.

StuartLC · Answer 1 · 2012-07-31T05:40:55.750

If ProductName is a form field that you intend displaying on the form, why not instead abstract all the fields of property into a separate Product entity. This should ease the maintenance of your app (and bring it more in line with patterns like MVC / MVVM), e.g.

public class Product
{
     public string ProductName{ get; set; }
     public int ProductSize{ get; set; }
     // etc
}

public partial class FormInventory : Form
{
   public FormInventory()
   {
   } 

   public Product Product
   {
      get;
      set;
   }
}

Edit :

IMO, the architecture presented by Rod Cerata's blog looks OK, but I believe it would be improved via encapsulation of a "ViewModel" for your Employee.

Have a look at EmployeePresenter.cs - you get lots of repetitive scraping code like this:

        _model.EmployeeID = _view.EmployeeID;
        _model.Lastname = _view.Lastname;
        _model.Firstname = _view.Firstname;
        _model.EmployeeType = _view.EmployeeType;
        _model.Salary = _view.Salary;
        _model.TAX = _view.TAX;

IMO would be improved by creating a new EmployeeViewModel class (which would be more or less the same as EmployeeModel, plus any 'screen' specific fields e.g. Title, "mode" (Edit, New, Read Only etc), and then using a tool like AutoMapper, which would reduce the code above.

I have updated the code in my Question. ProductName property gets and sets the textbox textProduct's value. My presenter will call ProductName property to get and set the value of the text box. I am currently following the MVP style explained in this [blog](http://cerquit.com/blogs/post/MVP-Part-I-e28093-Building-it-from-Scratch.aspx). Its simple and easy for me to understand. — krishnan, Jul 31 '12 at 05:19
thanks nonnb. ViewModel will be helpful, like u said if i abstract all the fields of view into a separate view model, i thought there will be a problem with retrieving and binding data from and to the view controls especially 'textboxes'. After searching I came across this [article](http://aviadezra.blogspot.in/2009/08/mvp-mvvm-winforms-data-binding.html). I never thought that the 'textbox' has a databinding property. Now i will be using viewmodel. I am not using automapper now. Thanks again for your answer. — krishnan, Jul 31 '12 at 12:55

score 1 · Accepted Answer · answered Jul 31 '12 at 04:58

1

1. Yes, simply use the new keyword, like public new string ProductName { get; set; }

2. No, it simply returns the name of the assembly.

3. Its used for debugging and some "reflection". I say "reflection" because it's more like a human-made reflection.

So, it's safe to go forward this way. But why don't you simply change it to MyCompanyProductName?

Regards

answered Jul 31 '12 at 04:58

Andre Calil

7,652
34
41

I have some six to seven properties in my form. If i rename this property alone to MyCompanyProductName, it will cause some inconstencies in my form. And also having the company name as a prefix for all the properties, it will be redundant. But renaming is the easy solution. just like @drumboog said, it will be less confusing. Thanks for your answer. – krishnan Jul 31 '12 at 05:37

Glen Hughes · Answer 3 · 2012-07-31T05:05:34.113

Using the 'new' keyword will suppress the warning. When you do this, the result of calling the ProductName property depends on Type of the variable that is used to referenced the form... for example, if you're calling the property from another class:

// Notice that we're only creating one object and
// assigning it to two different variables.
FormInventory explicitlyNameForm = new FormInventory();
Form referenceToBaseForm = explicitlyNameForm;

// Acting on the child reference (FormInventory) will
// operate on YOUR implementation of ProductName
explicitlyNameForm.ProductName = "Some Value";

// But acting on the parent reference (Form) will
// operate on the .NET implementation of ProductName
referenceToBaseForm.ProductName = "Some Other Value";

The end result will probably be what you want... the compiler knows which implementation to use based on how you've declared your variable. And since all references within the .NET framework reference the Form class, not your new class, there is no risk of affecting anything that happens within the .NET framework with respect to this property.

However, as the others have suggested, it may cause less confusion if you're able to rename the property.

thanks your answer helped me understanding how this 'new' keyword works. — krishnan, Jul 31 '12 at 05:47

ProductName hides System.Windows.Forms.Control.ProductName

3 Answers3