Yeah, it's so damn annoying to have to expand an auto property to do
raised events, but in some cases you need to, most of the time for
RaisePropertyChanges I'd opt to use a extension/helper method that
accepts a lambda:
RaisePropertyChange(()=> this.PropertyName);
But I'd only use that in instances where I'd really need to expand
that property out, but for most cases I've been employing the dynamic
proxy generator from castle, and also using a
NotifyPropertyChangedInterceptor I found online.
So All i need to do now is, have a class that implements
INotifyPropertyChanged, and all my automatic properties are declared
as virtual:
public virtual string MyProp { get; set; }
And have the proxy generate help instantiate my class, and helping me
raise all the property changes for properties marked virtual.
On Wed, Mar 23, 2011 at 1:56 PM, David Burela <david.bur...@gmail.com> wrote:
> 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
