This project is read-only.

FW Change request - Add [CallerMemberName] to NotifyChanged in ViewModel class

Sep 17, 2013 at 5:40 AM
Markus,

It might be nice to have an #if that checks the build version and if 4.5, uses the new CallerMemberName on NotifyChanged in the ViewModel class. I just updated my version, but I assume that others out there are still using 4.0.

Thanks,

Fletcher
Sep 19, 2013 at 5:38 AM
Yes, support for this would be nice. I have been thinking about that too.

I'd have to do it slightly different though. Currently, if no parameter is passed to NotifyChanged(), then the system will assume ALL properties have changed. It's a handy way to refresh everything. If I just add the [CallerMemberName] attribute, then the method name will always be passed, and now only the name of the updated property will be refreshed, so it would potentially break a whole lot of people's code. So I'd have to introduce a new method name, like NotifyChangedAuto() or something like that. Not exactly super-clean, but better than breaking stuff.

Doing a pre-compiler setting for different .NET versions is kind of a pain, really. Most people just download the DLLs. They don't want to recompile in 4.5 to get the new features. But I am considering to require .NET 4.5 going forward. Seems to me that it's been around long enough, and other people can always download the older DLLs if they want (or re-compile the older version themselves if they were so inclined). What do you think?


Markus
Sep 19, 2013 at 5:39 AM
Note: I have considered the possibility of using the call stack to find out the member name before, but always rejected it because of the overhead. CallerMemberName would be really nice, because it has no such overhead. So it's a likable idea.
Sep 20, 2013 at 9:27 PM
Markus,

I like your idea to use 4.5 moving forward. But keep the current source code up so that someone who has to use 4.0 can download it and then diff it with the current version to decide what new features they can implement.

For the Notifychanged, what about implementing a new method that does the same thing. Maybe PropertyChanged(). Then NotifyChanged can just call that method (or my code can). That way, the call is more consistent. then NotifyChanged can be used to indicate a complete refresh the way it does now. The fact that it supports an individual property as a parameter is simply a plus. Since if you add support for Callermembername, you will need such a method anyway, this could solve both issues. Just a thought.

Thanks,

Fletcher
Sep 23, 2013 at 7:11 AM
Yup, something along those lines. I will have to think about the details and the implications. But something along those lines makes sense to me.


Markus