Hiding inherited member (PropertyChanged)

Question

2.00/5 (1 vote)

See more:

Hi all!

I have hundreds of classes and all the classes implement INotifyPropertyChanged interface. All the classes are used individually but there are also cases where classes inhert each other so compiler gives lots of warnings that baseclass and derived class both have PropertyChanged event.

"ClassA hides inherited member 'PropertyChanged' from ClassB. Use the new keyword if hiding was intended."

So if I declare in every class

public event PropertyChangedEventHandler PropertyChanged;

as

new public event PropertyChangedEventHandler PropertyChanged;

So is it Ok if do this? Will databinding work when using class alone OR in scenarios where inheritation occur?

NOTE: I know that using baseclass wich offers PropertyChanged event with all the classes would be ideal solution, but unfortunatelly in this case common base class is not an option.

Also like to hear if there is another options

Hope you got idea :)

Cheers!

Posted 22-Feb-12 20:33pm

paleGegg0

Add a Solution

Comments

Sergey Alexandrovich Kryukov 23-Feb-12 2:42am

The only question here is: why did you try to do this?
--SA

3 solutions

Solution 2

If a class is statically inheriting from something which implements INotifyPropertyChanged, you don't need to explicitly implement it again. Just make sure the base class provides a way of notifying that you can still use (i.e. the method to fire the event is protected not private).

For the wider issues I refer you to SAK's answer.

Posted 22-Feb-12 23:31pm

BobJanova

Comments

Sergey Alexandrovich Kryukov 26-Feb-12 12:38pm

Right, a 5.
--SA

Solution 3

Not sure if this issue is resolved. This is one of the solutions should there be similar issue someone faces. I just resolved this one by changing the property changed event handler name.

The baseclass had this name "PropertyChanged", I had used the same name in my derived class and encountered this warning. I simply changed "PropertyChanged" to "xxx_PropertyChanged", where "xxx" is a suitable property/object name that you could provide. Got rid of this warning.

SA's explanation says it all.

Posted 27-Jan-15 20:50pm

TechBang

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-02-22T20:51:00

It would be OK if you knew why are you hiding in first place, but as you did not know and asked a question, this is most likely your mistake. This new keyword and this warning are designed specially for that.

In this context, the new means the following:

"Hey, comrade compiler, don't be so smart. I know myself that hiding PropertyChanged looks stupid. I do this dirty trick on purpose. Actually, I don't need this member. I just like the name of this member and want to use it for something semantically similar, but unrelated event, that's why I use the same name, as a rare exclusion from normal coding practices. Yes, I understand that in case I need to use inherited PropertyChanged, I will be able to use it through the qualified name base.PropertyChanged. So, please shut up your stupid warning; I know what I am doing."

Don't mist up this new and a constructor call.

As you are asking this question, this is not the case, most likely. Create a different event with some other name. The only case where you use the same name is when you override a virtual method or implement an interface method. This is a heart of OOP which you are supposed to know very well. Hiding has nothing in common with that. If you are not explicitly specify "override" but use the same name, you simply hide the inherited member behind a completely different member and get the warning for that; you can suppress this warning with new. But you cannot override an event, so all you do is hiding. I don't see a reason for doing it in your case.

[EDIT]

I basically understand your purpose. You just need to implement the interface INotifyPropertyChanged. Hiding would make your new "implementation" of the class totally fake. You need to just implement it in different classes. If one common base is not an option, you can use several common base classes with virtual implementation method. Another usual approach is a composed member of some "implementor class". (I don't know if this is a design pattern with a well-known name, but this is a typical and well-known design pattern.)

—SA