PropertyChanged: Cannot depend on Inherited member

sorry this is not going to happen.

I suggest instead of having a base VM with properties you have a shared interface.

if you dont like this i suggest you stop using Fody

it is a perfectly sensible suggestion

It is not a sensible suggestion. changing a base property should not “also trigger” a property on the child class. This is why no one has come across this in the 4 years the project has been running.

You have implemented all sorts of extensions that are useful for other situations but are less useful than this would be.

It doesnt matter how useful you think it is. You should not be doing it

are suggestion that fody SHOULD never work with solutions that use base classes. Thats fine but I think you will find that many developers use base classes.

No i did not say that.

Use a shared interface? This wouldnt solve anything

yes it would. for starters why do u have a base class? if it is to “save you code and not have to implement properties in child classes” then you should rethink your strategy. flattening you hierarchy and duplicating some properties will save you much pain in the future. If you need to have a common (castable) base then this is where interfaces can help you. eg if you want to use the Status property in multiple places then have some interface IExposeStatus with the Status property.

There is a reason people regularly say “use composition over inheritance”, it works. and VMs are one of the most common abusers of inheritance.

Your suggestion of “no base classes in view models” is totally impractical to 99% of experienced developers.

Again i didnt say this. and “99% of developers”… please

“Stop using Fody” is totally uncalled for, it is a perfectly sensible suggestion which doesnt deserve ridiculing or becoming defensive over.

i was not being rude or defensive. PropertyChanged.Fody is an opinionated approach to injecting INPC. if you dont like those opinions it is best you dont use it.

@dellycowboy that is because the implementation of DependsOn is to inject into the set of the property being depended on. it makes no sense to notify on IsVisible inside BaseVM.Status.

so sorry but this is simply not possible to support

You’re right, and that’s totally fair.

All I can do is support other community members, and hope someone forks before I do. After reading the comments, I wanted to address what I read. You’re right, no one owes us anything. And certainly not ridicule.

delly was shutdown for using inheritance to clean up his code and create a reusable framework, which isn’t all uncommon. I felt his suggestion could have been handled with more of an open mind, so I wanted to support him. Again, you’re right. No one has to change this and maybe no one will. But maybe my support will change something. It’s worth that maybe.

I understand your guy’s arguments about how the MDIC compiled code doesn’t make sense and would be a bad code smell to see a base class raise a property on a child class. However, I can think of other arguments in support of delly, too. I’m willing to elaborate, if interested.

I’ll close with saying the project does seem like a great project, over all. Well done. I’ve worked with reducing time on implementing INotifyPropertyChanged in different ways, but doing it with Fody is a neat way. I’m only using it on this one client project, and it’s been nice to work with up until this speedbump.

He did seem very opinionated, patronizing and aggressive.

It’s a shame the community isn’t being heard here.

you should probably include this behavior somewhere

At the very least, do this

No one owes you anything. This is a free project.

@dellycowboy You do realize your suggestion would produce the following code?

public class BaseVM: INotifyPropertyChanged
{
    private bool status;
    public bool Status {
        get { return status; }
        set {
            if (status == value)
                return;
            status = value;
            OnPropertyChanged("Status");
            OnPropertyChanged("IsVisible") // <-------- This line is problematic
        }
    } 
}

BaseVM raising a PropertyChanged event for IsVisible makes no sense. This suggests to me that Status and IsVisible should be in the same class, since one depends on the other.

If I saw this code I would question why the base object is firing events for it’s children.