6
815
0
2
1
0
4
public class PropertyChangedBase : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged = delegate { };
public void NotifyOfPropertyChange(string propertyName)
{
Execute.OnUIThread(() => PropertyChanged(this, new PropertyChangedEventArgs(propertyName)));
}
public void NotifyOfPropertyChange<TProperty>(Expression<Func<TProperty>> property)
{
var lambda = (LambdaExpression)property;
MemberExpression memberExpression;
if (lambda.Body is UnaryExpression)
{
var unaryExpression = (UnaryExpression)lambda.Body;
memberExpression = (MemberExpression)unaryExpression.Operand;
}
else memberExpression = (MemberExpression)lambda.Body;
NotifyOfPropertyChange(memberExpression.Member.Name);
}
}
Usage:
public class SomeViewModel : PropertyChangedBase
{
string name;
public string Name
{
get { return name; }
set
{
name = value;
NotifyOfPropertyChange(() => Name);
}
}
}
twitter
Mark 'c#' tag as 'like'
Mark 'c#' tag as 'ignore'
Fork
3 Feedback
I think this stack-exchange [proposal](http://area51.stackexchange.com/proposals/11464/code-review?referrer=aWNm_Pdc - greatwolf Sunday 16, 2011 9:38 AMYou must log in before you can give any feedback
0
One solution to avoid runtime checking and validation of properties, is by just doing it during development and debug mode only:
[Conditional("DEBUG")]
[DebuggerStepThrough]
private void ValidateProperty(string propertyName)
{
if (this.GetType().GetProperty(propertyName) == null)
throw new MissingMemberException(propertyName);
}
0
The problem with this is that it doesn't force compile-time checking of properties that are on the class. Instead it's better to use your PropertyChangedBase to take a generic type to constrain the properties that are available:
PropertyChangedBase<TObject>, then you end up with a NotifyPropertyChanged function which takes
Expression<Func<TObject, object>> instead of an action that can return an expression. While this is still up for abuse it at least implies that you're expecting something that belongs to TObject.
Also I wouldn't assume that you want your event notification to fire on the UI thread. creation of new UI objects and removing old objects has to happen on the UI thread, but INotifyPropertyChanged isn't specific to WPF/Silverlight.
0
OJ, I agree that it would be nice to have compile-time checking against properties on the class, but your solution doesn't really do that either (as you say, it's still up for abuse).
NotifyOfPropertyChange(a => a.Name);
could just as easily be replaced with something stupid like this and still compile just fine:
NotifyOfPropertyChange(a => new Object());
Instead, maybe you could just use a convention to say that you should always use
this:
NotifyOfPropertyChange(() => this.Name);
However, I have to agree that a => a.Name is slightly prettier than
() => this.Name. Unfortunately it comes with a rather odd-looking class declaration that might confuse quite a bit (I wasn't even sure it would work to be quite honest):
public class MainViewModel : PropertyChangedBase<MainViewModel>
As you can see, I'm arguing with myself here.. sorry about that.. ;-)
0
You must log in before you can post a comment
