I believe it was in this mailing list that we previously confirmed using GetCurrentMethod, even when included in convoluted ways, guarantees the method will not be inlined.
Can you show an example where GetCurrentMethod does not return the expected method? -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.) On 23 March 2011 14:27, David Kean <[email protected]> wrote: > Below is not guaranteed to work, if we inline the set, GetCurrentMethod will > return the wrong method. > > > > From: [email protected] [mailto:[email protected]] > On Behalf Of David Burela > Sent: Tuesday, March 22, 2011 7: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
