Caliburn.Micro uses Expressions

        public virtual void NotifyOfPropertyChange(string propertyName) {
            if(IsNotifying)
                Execute.OnUIThread(() =>
RaisePropertyChangedEventCore(propertyName));
        }

        public virtual void
NotifyOfPropertyChange<TProperty>(Expression<Func<TProperty>>
property) {
            NotifyOfPropertyChange(property.GetMemberInfo().Name);
        }


So then you can do:

private bool isBusy;
public bool IsBusy
{
    get { return isBusy; }
    set
    {
        isDialogProcessing = value;
        RaisePropertyChanged(() => IsBusy);
    }
}

It works and refactoring tools picks it up. Not sure of the performance
implications but I'd guess they aren't worse than doing a stackwalk in
GetCurrentMethod and you can use them to raise changed events on other
properties

Also, some colleagues and I experimented with building a T4 template that
scans your code for private variables and wraps them with
INotifyPropertyChanged properties in a partial class (with partial methods
for before the change and after). We got it working but haven't used it in
anger yet

On Wed, Mar 23, 2011 at 10:56 AM, 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
>

Reply via email to