But I like using a few extension methods pulled from ReactiveUI libraries.
public static TRet RaiseAndSetIfChanged<TObj, TRet>(this TObj vm,
Expression<Func<TObj, TRet>> property, ref TRet backingField, TRet newValue)
where TObj : ViewModelBase {
if (EqualityComparer<TRet>.Default.Equals(backingField, newValue)) {
return newValue;
}
backingField = newValue;
vm.RaisePropertyChanged(property);
return newValue;
string _thirdProperty;
public string ThirdProperty {
get {
return _thirdProperty;
}
set {
this.RaiseAndSetIfChanged(x => x.ThirdProperty, ref
_thirdProperty, value);
}
}
From: [email protected] [mailto:[email protected]] On
Behalf Of Chris Walsh
Sent: Wednesday, 23 March 2011 1:59 PM
To: ozDotNet
Subject: RE: Raising property changed events
Apparently (according to Brendon Forster :)) All the cool kids are using this.
http://code.google.com/p/notifypropertyweaver/
From: [email protected] [mailto:[email protected]] On
Behalf Of David Burela
Sent: Wednesday, 23 March 2011 1:57 PM
To: ozDotNet
Subject: Raising property changed events
Raising property changed events seems like something that most applications
need to do at some stage. C#3 introduced the auto property i.e. public bool
IsBusy { get; set; }
I am surprised that there isn't a way built into the framework to automatically
raise changed events
Anyway, i saw this code used at a client site. it seems like a smart way to
handle the raised event without using fragile strings that might not get
updated when you change the property name
private bool isBusy;
public bool IsBusy
{
get { return isBusy; }
set
{
isDialogProcessing = value;
RaisePropertyChanged(System.Reflection.MethodBase.GetCurrentMethod().Name.Substring(4));
}
}
Thought I'd throw it out there. See how other people are handling property
changed events in their own projects.
I'm sure there is an AOP way of introducing them. But all the AOP demos I have
watched seem to increase compilation times by heaps.
-David Burela
