RE: Raising property changed events
+1. NotifyPropertyWeaver is the closest thing to it just works, short of the
C# team actually caring about what the language is used for beyond Fibonacci
sequence calculators in console apps.
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On
Behalf Of Chris Walsh
Sent: Wednesday, 23 March 2011 12: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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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
Re: Raising property changed events
On Thu, Mar 24, 2011 at 4:42 PM, Stephen Price step...@littlevoices.com wrote: Thanks David. I feel much happier about my rant now. I don't usually do them, but really happy to know that it's not fallen on deaf ears. Passing it up the chain is the best thing I could hope for, short of the documentation actually being improved. :) The docs are terrible though and have been for several years, as others have said. I don't think comments here will change that. David's comments may provide reasons but it's clear MS just doesn't value it; which is fine, they don't really have to, that's why they promote MVP's and related people and sites, to allow the community to document it. It works, to a degree. But it'd be nice if one day the MSDN wasn't (in general) widely considered rubbish. The most annoying part, for me, is that MS pushes the onus of work on us: You help us improve it! Make Suggestions! Rate it! Bah. You make it usable, then we'll talk about how awesome it is to our friends. In the mean time we'll continue to be frustrated by it. Reporting bugs or making suggestsions is always a frustrating process; it relies on many people doing it, and your suggestions even being good (which they may not be). Even just the clicking-ness of MSDN is shocking. JavaDocs, at least as far as I remember, were beautiful. That said, sometimes I do find MSDN useful; and at least recently been specifically annoyed by it. But I think that's because I've stopped reading it (or stopped learning new things :P) -- Noon Silk http://dnoondt.wordpress.com/ (Noon Silk) | http://www.mirios.com.au:8081 Fancy a quantum lunch? http://www.mirios.com.au:8081/index.php?title=Quantum_Lunch Every morning when I wake up, I experience an exquisite joy — the joy of being this signature.
RE: Raising property changed events
I chased this up with one the devs on the JIT team. He confirmed that the JIT/NGEN doesn't give this guarantee, both inlining and tail calls can cause Assembly.GetExecutingAssembly, Assembly.GetCallingAssembly and Method.GetCurrentMethod to return incorrect results. You can somewhat mitigate that by marking your method with NoInlining (to prevent inlining) and NoOptimization (to prevent the JIT spitting out tail calls)[1], however, it is still possible for this to return incorrect results in certain other situations. http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions.aspx -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Kean Sent: Tuesday, March 22, 2011 10:06 PM To: ozDotNet Subject: RE: Raising property changed events Hmm, I'll check internally, but I'd be surprised if we give that guarantee. We're free to change our inlining policy at any time, in fact, we did just that in 3.5 SP1 x64 which broke a lot of customers who were relying on Assembly.GetExecutingAssembly() without explicitly turning off inlining for the method. Whether you can repro something now, is not a good indication of whether we'll continue to support in a future service pack or version - always check the docs. However, in saying that, the docs don't really make it clear that this might not work correctly in certain situations. In which case, if we don't give the above guarantee I'll make sure they call it out. -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Mark Hurd Sent: Tuesday, March 22, 2011 9:36 PM To: ozDotNet Subject: Re: Raising property changed events On 23 March 2011 15:00, Mark Hurd markeh...@gmail.com wrote: 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. Gmail says GetCurrentMethod has /not/ been mentioned before on this mailing list since I've been part of it, so I'm remembering that wrong. Can you show an example where GetCurrentMethod does not return the expected method? This request still stands however. -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.)
Re: GetCurrentMethod possibly returning the wrong method (was Re: Raising property changed events)
Had no idea about that. Thanks for following it up! On 25 March 2011 11:19, Mark Hurd markeh...@gmail.com wrote: Thanks for that clarification. However GoogleDesktop found my previous recollection discussing this was in the Microsoft NewsGroups, which now Googling for the subject of that exchange Reflection and compiler inlining found this other reply: On 2009-12-11 6:18, Alex Clark wrote: Yes, because any method that calls MethodBase.GetCurrentMethod() will not be inlined. This is because .GetCurrentMethod() includes a StackCrawlMark, a special magical enum for methods that need to walk the stack (like .GetCurrentMethod() predictably needs, to look for its caller) that prevents the caller from being inlined. Trying to be clever by sticking the call in a delegate like Mark did will not upset this, because methods that call delegates are not inlined either. (as retrieved from http://www.eggheadcafe.com/software/aspnet/35469613/reflection-and-compiler-inlining.aspx but there are a number of clones of this info) So have things changed or was Alex Clark wrong? -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.) On 25 March 2011 02:40, David Kean david.k...@microsoft.com wrote: I chased this up with one the devs on the JIT team. He confirmed that the JIT/NGEN doesn't give this guarantee, both inlining and tail calls can cause Assembly.GetExecutingAssembly, Assembly.GetCallingAssembly and Method.GetCurrentMethod to return incorrect results. You can somewhat mitigate that by marking your method with NoInlining (to prevent inlining) and NoOptimization (to prevent the JIT spitting out tail calls)[1], however, it is still possible for this to return incorrect results in certain other situations. http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions.aspx -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] On Behalf Of David Kean Sent: Tuesday, March 22, 2011 10:06 PM To: ozDotNet Subject: RE: Raising property changed events Hmm, I'll check internally, but I'd be surprised if we give that guarantee. We're free to change our inlining policy at any time, in fact, we did just that in 3.5 SP1 x64 which broke a lot of customers who were relying on Assembly.GetExecutingAssembly() without explicitly turning off inlining for the method. Whether you can repro something now, is not a good indication of whether we'll continue to support in a future service pack or version - always check the docs. However, in saying that, the docs don't really make it clear that this might not work correctly in certain situations. In which case, if we don't give the above guarantee I'll make sure they call it out. -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] On Behalf Of Mark Hurd Sent: Tuesday, March 22, 2011 9:36 PM To: ozDotNet Subject: Re: Raising property changed events On 23 March 2011 15:00, Mark Hurd markeh...@gmail.com wrote: 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. Gmail says GetCurrentMethod has /not/ been mentioned before on this mailing list since I've been part of it, so I'm remembering that wrong. Can you show an example where GetCurrentMethod does not return the expected method? This request still stands however. -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.)
RE: GetCurrentMethod possibly returning the wrong method (was Re: Raising property changed events)
Okay, it turns out that I asked the wrong question to the JIT dev. I asked 'Does the JIT has any special knowledge about GetCurrentMethod when determining whether to inline a method?'. What I should have asked was 'Does the JIT have any special knowledge about *the characteristics* of a method like GetCurrentMethod when determining whether to inline a method?' The JIT guys are not managed developers - they talk in terms of CLI intrinsics not particular APIs. The behavior you are seeing on that thread is correct. Callers of GetCurrentMethod will not be inlined. It is *not*, however, because of what Jeroen states. The JIT does not take into an account StackCrawlMark when determine whether to inline a caller, or the callee itself (it's not a coincidence that every method that gets a StackCrawlMark, is also marked as Noinlining). It's actually due to another reason; GetCurrentMethod is marked as RequireSecObject[1]. This method attribute (applied via the internal-only pseudo attribute, DynamicSecurityMethodAttribute) is used to indicate to the JIT that it should store extra information on the stack for methods that call it. It also has a side-effect of preventing those same methods from being inlined. One thing to note is that Assembly.GetCallingAssembly and Assembly.GetExecutingAssembly are not marked as RequireSecObject so these do not have the same guarantee. As the docs call out for Assembly.GetCallingAssembly you can't prevent your callers from being inlined (other than having opt out), however, the later, GetExecutingAssembly, you can apply NoInlining and NoOptimization to the method calling it to prevent it from getting the wrong results. [1] http://msdn.microsoft.com/en-US/library/system.reflection.methodattributes -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Mark Hurd Sent: Thursday, March 24, 2011 5:20 PM To: ozDotNet Subject: Re: GetCurrentMethod possibly returning the wrong method (was Re: Raising property changed events) Thanks for that clarification. However GoogleDesktop found my previous recollection discussing this was in the Microsoft NewsGroups, which now Googling for the subject of that exchange Reflection and compiler inlining found this other reply: On 2009-12-11 6:18, Alex Clark wrote: Yes, because any method that calls MethodBase.GetCurrentMethod() will not be inlined. This is because .GetCurrentMethod() includes a StackCrawlMark, a special magical enum for methods that need to walk the stack (like .GetCurrentMethod() predictably needs, to look for its caller) that prevents the caller from being inlined. Trying to be clever by sticking the call in a delegate like Mark did will not upset this, because methods that call delegates are not inlined either. (as retrieved from http://www.eggheadcafe.com/software/aspnet/35469613/reflection-and-compiler-inlining.aspx but there are a number of clones of this info) So have things changed or was Alex Clark wrong? -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.) On 25 March 2011 02:40, David Kean david.k...@microsoft.com wrote: I chased this up with one the devs on the JIT team. He confirmed that the JIT/NGEN doesn't give this guarantee, both inlining and tail calls can cause Assembly.GetExecutingAssembly, Assembly.GetCallingAssembly and Method.GetCurrentMethod to return incorrect results. You can somewhat mitigate that by marking your method with NoInlining (to prevent inlining) and NoOptimization (to prevent the JIT spitting out tail calls)[1], however, it is still possible for this to return incorrect results in certain other situations. http://msdn.microsoft.com/en-us/library/system.runtime.compilerservice s.methodimploptions.aspx -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Kean Sent: Tuesday, March 22, 2011 10:06 PM To: ozDotNet Subject: RE: Raising property changed events Hmm, I'll check internally, but I'd be surprised if we give that guarantee. We're free to change our inlining policy at any time, in fact, we did just that in 3.5 SP1 x64 which broke a lot of customers who were relying on Assembly.GetExecutingAssembly() without explicitly turning off inlining for the method. Whether you can repro something now, is not a good indication of whether we'll continue to support in a future service pack or version - always check the docs. However, in saying that, the docs don't really make it clear that this might not work correctly in certain situations. In which case, if we don't give the above guarantee I'll make sure they call it out. -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Mark Hurd Sent: Tuesday, March 22, 2011 9:36 PM To: ozDotNet Subject: Re: Raising property changed events On 23 March 2011 15:00, Mark Hurd markeh
Re: Raising property changed events
I was going to use this an opportunity to vent about the msdn documentation and then discovered that the page on this particular method is better than what I usually get on msdn docs. http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getexecutingassembly.aspx Assembly.GetExecutingAssembly Method Gets the assembly that contains the code that is currently executing. rant so does anyone else get frustrated with this kind of documentation? It's like finding comments in your code that say Gets the value from the property. yeah, I can see that from the code. Tell me something about why, or how to use it? 95% of the msdn doc pages have no examples. Typically, this particular one DOES but I'm sure thats because I wanted to rant about it and murphy's law was invoked. Most don't. Some explanations on what things actually do or why. Some examples. Please. We're guessing here and don't always have time or skills to crack open the dll with decompiler of the month and figure it out for ourselves. More examples please. Free standing, spelt out, working examples. Pretend we want to know how to use the methods. Give us an instruction manual. Please!! You'd make some happy people if you showed us how to use the framework. Throw some unit tests in there or something. /rant thanks, Stephen On Wed, Mar 23, 2011 at 1:06 PM, David Kean david.k...@microsoft.comwrote: Hmm, I'll check internally, but I'd be surprised if we give that guarantee. We're free to change our inlining policy at any time, in fact, we did just that in 3.5 SP1 x64 which broke a lot of customers who were relying on Assembly.GetExecutingAssembly() without explicitly turning off inlining for the method. Whether you can repro something now, is not a good indication of whether we'll continue to support in a future service pack or version - always check the docs. However, in saying that, the docs don't really make it clear that this might not work correctly in certain situations. In which case, if we don't give the above guarantee I'll make sure they call it out. -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Mark Hurd Sent: Tuesday, March 22, 2011 9:36 PM To: ozDotNet Subject: Re: Raising property changed events On 23 March 2011 15:00, Mark Hurd markeh...@gmail.com wrote: 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. Gmail says GetCurrentMethod has /not/ been mentioned before on this mailing list since I've been part of it, so I'm remembering that wrong. Can you show an example where GetCurrentMethod does not return the expected method? This request still stands however. -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.)
Re: Raising property changed events
Imo. This has been the problem with msdn since the inception of .net. The last usable msdn was '98. Where you could find examples on all methods with related BUG: documents linked. The xml autodoc and java suffer from the same problem, the developers are there to write code and not provide examples. I haven't pressed F1 in visual studio since early 2001. It's a waste of time installing the docs as google will give you better and more concise information in half the time. .02c Davy When all you have is a hammer, every problem looks like a nail. I feel much the same way about xml -Original Message- From: Stephen Price step...@littlevoices.com Sender: ozdotnet-boun...@ozdotnet.com Date: Wed, 23 Mar 2011 21:48:10 To: ozDotNetozdotnet@ozdotnet.com Reply-To: ozDotNet ozdotnet@ozdotnet.com Subject: Re: Raising property changed events I was going to use this an opportunity to vent about the msdn documentation and then discovered that the page on this particular method is better than what I usually get on msdn docs. http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getexecutingassembly.aspx Assembly.GetExecutingAssembly Method Gets the assembly that contains the code that is currently executing. rant so does anyone else get frustrated with this kind of documentation? It's like finding comments in your code that say Gets the value from the property. yeah, I can see that from the code. Tell me something about why, or how to use it? 95% of the msdn doc pages have no examples. Typically, this particular one DOES but I'm sure thats because I wanted to rant about it and murphy's law was invoked. Most don't. Some explanations on what things actually do or why. Some examples. Please. We're guessing here and don't always have time or skills to crack open the dll with decompiler of the month and figure it out for ourselves. More examples please. Free standing, spelt out, working examples. Pretend we want to know how to use the methods. Give us an instruction manual. Please!! You'd make some happy people if you showed us how to use the framework. Throw some unit tests in there or something. /rant thanks, Stephen On Wed, Mar 23, 2011 at 1:06 PM, David Kean david.k...@microsoft.comwrote: Hmm, I'll check internally, but I'd be surprised if we give that guarantee. We're free to change our inlining policy at any time, in fact, we did just that in 3.5 SP1 x64 which broke a lot of customers who were relying on Assembly.GetExecutingAssembly() without explicitly turning off inlining for the method. Whether you can repro something now, is not a good indication of whether we'll continue to support in a future service pack or version - always check the docs. However, in saying that, the docs don't really make it clear that this might not work correctly in certain situations. In which case, if we don't give the above guarantee I'll make sure they call it out. -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Mark Hurd Sent: Tuesday, March 22, 2011 9:36 PM To: ozDotNet Subject: Re: Raising property changed events On 23 March 2011 15:00, Mark Hurd markeh...@gmail.com wrote: 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. Gmail says GetCurrentMethod has /not/ been mentioned before on this mailing list since I've been part of it, so I'm remembering that wrong. Can you show an example where GetCurrentMethod does not return the expected method? This request still stands however. -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.)
Re: Raising property changed events
On 24 March 2011 00:54, djones...@gmail.com wrote: snip I haven't pressed F1 in visual studio since early 2001. It's a waste of time installing the docs as google will give you better and more concise information in half the time. /snip Couldn't agree more. SQL Server documentation however is and always has been excellent (IMHO). They set the benchmark at Microsoft that others there fail to follow. Cheers Dave
RE: Raising property changed events
If you come across pages where you think the docs need improvement, please use the Rating box in the top right. Given that there's something like 200,000+ pages on MSDN, the UE (doc guys) combine that with page views to focus on low rated, high viewed pages first. From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of djones...@gmail.com Sent: Wednesday, March 23, 2011 6:54 AM To: ozDotNet Subject: Re: Raising property changed events Imo. This has been the problem with msdn since the inception of .net. The last usable msdn was '98. Where you could find examples on all methods with related BUG: documents linked. The xml autodoc and java suffer from the same problem, the developers are there to write code and not provide examples. I haven't pressed F1 in visual studio since early 2001. It's a waste of time installing the docs as google will give you better and more concise information in half the time. .02c Davy When all you have is a hammer, every problem looks like a nail. I feel much the same way about xml From: Stephen Price step...@littlevoices.com Sender: ozdotnet-boun...@ozdotnet.com Date: Wed, 23 Mar 2011 21:48:10 +0800 To: ozDotNetozdotnet@ozdotnet.com ReplyTo: ozDotNet ozdotnet@ozdotnet.com Subject: Re: Raising property changed events I was going to use this an opportunity to vent about the msdn documentation and then discovered that the page on this particular method is better than what I usually get on msdn docs. http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getexecutingassembly.aspx Assembly.GetExecutingAssembly Method Gets the assembly that contains the code that is currently executing. rant so does anyone else get frustrated with this kind of documentation? It's like finding comments in your code that say Gets the value from the property. yeah, I can see that from the code. Tell me something about why, or how to use it? 95% of the msdn doc pages have no examples. Typically, this particular one DOES but I'm sure thats because I wanted to rant about it and murphy's law was invoked. Most don't. Some explanations on what things actually do or why. Some examples. Please. We're guessing here and don't always have time or skills to crack open the dll with decompiler of the month and figure it out for ourselves. More examples please. Free standing, spelt out, working examples. Pretend we want to know how to use the methods. Give us an instruction manual. Please!! You'd make some happy people if you showed us how to use the framework. Throw some unit tests in there or something. /rant thanks, Stephen On Wed, Mar 23, 2011 at 1:06 PM, David Kean david.k...@microsoft.commailto:david.k...@microsoft.com wrote: Hmm, I'll check internally, but I'd be surprised if we give that guarantee. We're free to change our inlining policy at any time, in fact, we did just that in 3.5 SP1 x64 which broke a lot of customers who were relying on Assembly.GetExecutingAssembly() without explicitly turning off inlining for the method. Whether you can repro something now, is not a good indication of whether we'll continue to support in a future service pack or version - always check the docs. However, in saying that, the docs don't really make it clear that this might not work correctly in certain situations. In which case, if we don't give the above guarantee I'll make sure they call it out. -Original Message- From: ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Mark Hurd Sent: Tuesday, March 22, 2011 9:36 PM To: ozDotNet Subject: Re: Raising property changed events On 23 March 2011 15:00, Mark Hurd markeh...@gmail.commailto:markeh...@gmail.com wrote: 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. Gmail says GetCurrentMethod has /not/ been mentioned before on this mailing list since I've been part of it, so I'm remembering that wrong. Can you show an example where GetCurrentMethod does not return the expected method? This request still stands however. -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.)
RE: Raising property changed events
David, I think that Stephen's original rant was not that this was one example of a page documentation needing improvement, but that the entire style of the documentation is so minimal as to be close to useless. Unless I'm getting to the wrong bits, very little of the documentation I reach initially on MSDN is of any more use than confirming syntactic correctness and the most minimal explanation of the usage variation. And as Stephen pointed out, sometimes almost laughably obvious explanations of usage at that. My recollections of earlier versions were that they contained much more descriptive information, examples, guidance on the use of methods and the like. As stated below, it starts to look like Google gives broader information than MSDN does. Cheers, Trevor From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Kean Sent: Thursday, 24 March 2011 2:17 AM To: djones...@gmail.com; ozDotNet Subject: RE: Raising property changed events If you come across pages where you think the docs need improvement, please use the Rating box in the top right. Given that there's something like 200,000+ pages on MSDN, the UE (doc guys) combine that with page views to focus on low rated, high viewed pages first. From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of djones...@gmail.com Sent: Wednesday, March 23, 2011 6:54 AM To: ozDotNet Subject: Re: Raising property changed events Imo. This has been the problem with msdn since the inception of .net. The last usable msdn was '98. Where you could find examples on all methods with related BUG: documents linked. The xml autodoc and java suffer from the same problem, the developers are there to write code and not provide examples. I haven't pressed F1 in visual studio since early 2001. It's a waste of time installing the docs as google will give you better and more concise information in half the time. .02c Davy When all you have is a hammer, every problem looks like a nail. I feel much the same way about xml _ From: Stephen Price step...@littlevoices.com Sender: ozdotnet-boun...@ozdotnet.com Date: Wed, 23 Mar 2011 21:48:10 +0800 To: ozDotNetozdotnet@ozdotnet.com ReplyTo: ozDotNet ozdotnet@ozdotnet.com Subject: Re: Raising property changed events I was going to use this an opportunity to vent about the msdn documentation and then discovered that the page on this particular method is better than what I usually get on msdn docs. http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getexecut ingassembly.aspx Assembly.GetExecutingAssembly Method Gets the assembly that contains the code that is currently executing. rant so does anyone else get frustrated with this kind of documentation? It's like finding comments in your code that say Gets the value from the property. yeah, I can see that from the code. Tell me something about why, or how to use it? 95% of the msdn doc pages have no examples. Typically, this particular one DOES but I'm sure thats because I wanted to rant about it and murphy's law was invoked. Most don't. Some explanations on what things actually do or why. Some examples. Please. We're guessing here and don't always have time or skills to crack open the dll with decompiler of the month and figure it out for ourselves. More examples please. Free standing, spelt out, working examples. Pretend we want to know how to use the methods. Give us an instruction manual. Please!! You'd make some happy people if you showed us how to use the framework. Throw some unit tests in there or something. /rant thanks, Stephen On Wed, Mar 23, 2011 at 1:06 PM, David Kean david.k...@microsoft.com wrote: Hmm, I'll check internally, but I'd be surprised if we give that guarantee. We're free to change our inlining policy at any time, in fact, we did just that in 3.5 SP1 x64 which broke a lot of customers who were relying on Assembly.GetExecutingAssembly() without explicitly turning off inlining for the method. Whether you can repro something now, is not a good indication of whether we'll continue to support in a future service pack or version - always check the docs. However, in saying that, the docs don't really make it clear that this might not work correctly in certain situations. In which case, if we don't give the above guarantee I'll make sure they call it out. -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Mark Hurd Sent: Tuesday, March 22, 2011 9:36 PM To: ozDotNet Subject: Re: Raising property changed events On 23 March 2011 15:00, Mark Hurd markeh...@gmail.com wrote: 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. Gmail says GetCurrentMethod has /not/ been mentioned before on this mailing list since I've
Re: Raising property changed events
Agree 100% with Stephen comments. For the amount of money and resources Microsoft must put into MSDN it is crazy that you get better, more useable results using a search engine written by their competitor, which often points to other sites like StackOverflow or ExpertsExchange rather than MSDN. MSDN has the potential to be the absolute BEST developer resource out there if they would only target the editorial effort more appropriately. On 24 March 2011 09:38, Trevor Andrew tand...@tassoc.com.au wrote: David, I think that Stephen’s original rant was not that this was one example of a page documentation needing improvement, but that the entire style of the documentation is so minimal as to be close to useless. Unless I’m getting to the wrong bits, very little of the documentation I reach initially on MSDN is of any more use than confirming syntactic correctness and the most minimal explanation of the usage variation. And as Stephen pointed out, sometimes almost laughably obvious explanations of usage at that. My recollections of earlier versions were that they contained much more descriptive information, examples, guidance on the use of methods and the like. As stated below, it starts to look like Google gives broader information than MSDN does. Cheers, Trevor** *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *David Kean *Sent:* Thursday, 24 March 2011 2:17 AM *To:* djones...@gmail.com; ozDotNet *Subject:* RE: Raising property changed events If you come across pages where you think the docs need improvement, please use the Rating box in the top right. Given that there’s something like 200,000+ pages on MSDN, the UE (doc guys) combine that with page views to focus on low rated, high viewed pages first. *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *djones...@gmail.com *Sent:* Wednesday, March 23, 2011 6:54 AM *To:* ozDotNet *Subject:* Re: Raising property changed events Imo. This has been the problem with msdn since the inception of .net. The last usable msdn was '98. Where you could find examples on all methods with related BUG: documents linked. The xml autodoc and java suffer from the same problem, the developers are there to write code and not provide examples. I haven't pressed F1 in visual studio since early 2001. It's a waste of time installing the docs as google will give you better and more concise information in half the time. .02c Davy When all you have is a hammer, every problem looks like a nail. I feel much the same way about xml -- *From: *Stephen Price step...@littlevoices.com *Sender: *ozdotnet-boun...@ozdotnet.com *Date: *Wed, 23 Mar 2011 21:48:10 +0800 *To: *ozDotNetozdotnet@ozdotnet.com *ReplyTo: *ozDotNet ozdotnet@ozdotnet.com *Subject: *Re: Raising property changed events I was going to use this an opportunity to vent about the msdn documentation and then discovered that the page on this particular method is better than what I usually get on msdn docs. http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getexecutingassembly.aspx Assembly.GetExecutingAssembly Method Gets the assembly that contains the code that is currently executing. rant so does anyone else get frustrated with this kind of documentation? It's like finding comments in your code that say Gets the value from the property. yeah, I can see that from the code. Tell me something about why, or how to use it? 95% of the msdn doc pages have no examples. Typically, this particular one DOES but I'm sure thats because I wanted to rant about it and murphy's law was invoked. Most don't. Some explanations on what things actually do or why. Some examples. Please. We're guessing here and don't always have time or skills to crack open the dll with decompiler of the month and figure it out for ourselves. More examples please. Free standing, spelt out, working examples. Pretend we want to know how to use the methods. Give us an instruction manual. Please!! You'd make some happy people if you showed us how to use the framework. Throw some unit tests in there or something. /rant thanks, Stephen On Wed, Mar 23, 2011 at 1:06 PM, David Kean david.k...@microsoft.com wrote: Hmm, I'll check internally, but I'd be surprised if we give that guarantee. We're free to change our inlining policy at any time, in fact, we did just that in 3.5 SP1 x64 which broke a lot of customers who were relying on Assembly.GetExecutingAssembly() without explicitly turning off inlining for the method. Whether you can repro something now, is not a good indication of whether we'll continue to support in a future service pack or version - always check the docs. However, in saying that, the docs don't really make it clear that this might not work correctly in certain situations. In which case
Re: Raising property changed events
Assuming around 200 people on the list, if we each take 1000 pages we should be able to tag them all with a please provide examples I get what you are saying we can post on the pages asking for improvement. Doesn't help you at that moment. It does show that documentation wasn't a priority. Someone wrote the code once how come that person, or someone following closely behind didn't document this public facing class/method When it was written? Going back and documenting it all now is a mammoth task. Technology is being invented at a pace faster than you can learn it, we need to be making it easier to learn not harder. Agree with Grant. This is an opportunity to really shine. On Thu, Mar 24, 2011 at 7:38 AM, Trevor Andrew tand...@tassoc.com.auwrote: David, I think that Stephen’s original rant was not that this was one example of a page documentation needing improvement, but that the entire style of the documentation is so minimal as to be close to useless. Unless I’m getting to the wrong bits, very little of the documentation I reach initially on MSDN is of any more use than confirming syntactic correctness and the most minimal explanation of the usage variation. And as Stephen pointed out, sometimes almost laughably obvious explanations of usage at that. My recollections of earlier versions were that they contained much more descriptive information, examples, guidance on the use of methods and the like. As stated below, it starts to look like Google gives broader information than MSDN does. Cheers, Trevor** *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *David Kean *Sent:* Thursday, 24 March 2011 2:17 AM *To:* djones...@gmail.com; ozDotNet *Subject:* RE: Raising property changed events If you come across pages where you think the docs need improvement, please use the Rating box in the top right. Given that there’s something like 200,000+ pages on MSDN, the UE (doc guys) combine that with page views to focus on low rated, high viewed pages first. *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *djones...@gmail.com *Sent:* Wednesday, March 23, 2011 6:54 AM *To:* ozDotNet *Subject:* Re: Raising property changed events Imo. This has been the problem with msdn since the inception of .net. The last usable msdn was '98. Where you could find examples on all methods with related BUG: documents linked. The xml autodoc and java suffer from the same problem, the developers are there to write code and not provide examples. I haven't pressed F1 in visual studio since early 2001. It's a waste of time installing the docs as google will give you better and more concise information in half the time. .02c Davy When all you have is a hammer, every problem looks like a nail. I feel much the same way about xml -- *From: *Stephen Price step...@littlevoices.com *Sender: *ozdotnet-boun...@ozdotnet.com *Date: *Wed, 23 Mar 2011 21:48:10 +0800 *To: *ozDotNetozdotnet@ozdotnet.com *ReplyTo: *ozDotNet ozdotnet@ozdotnet.com *Subject: *Re: Raising property changed events I was going to use this an opportunity to vent about the msdn documentation and then discovered that the page on this particular method is better than what I usually get on msdn docs. http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getexecutingassembly.aspx Assembly.GetExecutingAssembly Method Gets the assembly that contains the code that is currently executing. rant so does anyone else get frustrated with this kind of documentation? It's like finding comments in your code that say Gets the value from the property. yeah, I can see that from the code. Tell me something about why, or how to use it? 95% of the msdn doc pages have no examples. Typically, this particular one DOES but I'm sure thats because I wanted to rant about it and murphy's law was invoked. Most don't. Some explanations on what things actually do or why. Some examples. Please. We're guessing here and don't always have time or skills to crack open the dll with decompiler of the month and figure it out for ourselves. More examples please. Free standing, spelt out, working examples. Pretend we want to know how to use the methods. Give us an instruction manual. Please!! You'd make some happy people if you showed us how to use the framework. Throw some unit tests in there or something. /rant thanks, Stephen On Wed, Mar 23, 2011 at 1:06 PM, David Kean david.k...@microsoft.com wrote: Hmm, I'll check internally, but I'd be surprised if we give that guarantee. We're free to change our inlining policy at any time, in fact, we did just that in 3.5 SP1 x64 which broke a lot of customers who were relying on Assembly.GetExecutingAssembly() without explicitly turning off inlining for the method. Whether you can repro something now
RE: Raising property changed events
First of all, I understand your points. I also get a little frustrated by documentation in certain areas of the product (VS Extensibility docs are frustrating me at the moment) - one of the reasons that I add Community comments to the bottom of the page when I see something missing. However, despite what it looks like on the outside, documentation is a priority, both on the content side and infrastructure side of things (Lightweight view is a perfect example) There's a couple of reasons why the docs are sparse, lacking examples, or just bad: 1) There's a lot of it. .NET Framework's surface area doubled between 3.0 and 4.0. Whether that's a good thing or not is in the eye of the beholder, but it makes it especially hard to write good docs on all members. 2) Developers aren't doc writers. While I do see some good XML comments written by developers internally, it's usually a rarity - and spending time on this means less features. Less features means complaints about missing features. It's a catch-22. 3) On some teams the doc writers don't have a lot to do with the feature team. While not true on my team (BCL) where the doc team turns up to every spec review team meeting, other teams I've been on the doc writer lives in a completely separate building and doesn't get involved until after the team is feature complete. We do need to improve on this. 4) It's not worth the return on investment to heavily doc every single member. As mentioned below, there's over 200,000 pages on MSDN, some with under 10 pages view total. We need to make sure we make the right call around what members people are having trouble with and what members need examples. However, we're also continually updating the docs every month. For example, we recently overhauled the Stringhttp://msdn.microsoft.com/en-us/library/system.string class docs last year, this is despite this class practically not changing for over 5 years (I think we added a couple of methods in 4.0). Please also don't get me wrong, I'm not trying to make excuses, but rather trying to be honest. Although I can't directly impact the docs as a whole (other adding comments to them where I can, and making sure my feature's docs are good) - I will forward this thread onto a couple of people who can impact them. From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Stephen Price Sent: Wednesday, March 23, 2011 7:26 PM To: ozDotNet Subject: Re: Raising property changed events Assuming around 200 people on the list, if we each take 1000 pages we should be able to tag them all with a please provide examples I get what you are saying we can post on the pages asking for improvement. Doesn't help you at that moment. It does show that documentation wasn't a priority. Someone wrote the code once how come that person, or someone following closely behind didn't document this public facing class/method When it was written? Going back and documenting it all now is a mammoth task. Technology is being invented at a pace faster than you can learn it, we need to be making it easier to learn not harder. Agree with Grant. This is an opportunity to really shine. On Thu, Mar 24, 2011 at 7:38 AM, Trevor Andrew tand...@tassoc.com.aumailto:tand...@tassoc.com.au wrote: David, I think that Stephen's original rant was not that this was one example of a page documentation needing improvement, but that the entire style of the documentation is so minimal as to be close to useless. Unless I'm getting to the wrong bits, very little of the documentation I reach initially on MSDN is of any more use than confirming syntactic correctness and the most minimal explanation of the usage variation. And as Stephen pointed out, sometimes almost laughably obvious explanations of usage at that. My recollections of earlier versions were that they contained much more descriptive information, examples, guidance on the use of methods and the like. As stated below, it starts to look like Google gives broader information than MSDN does. Cheers, Trevor From: ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Kean Sent: Thursday, 24 March 2011 2:17 AM To: djones...@gmail.commailto:djones...@gmail.com; ozDotNet Subject: RE: Raising property changed events If you come across pages where you think the docs need improvement, please use the Rating box in the top right. Given that there's something like 200,000+ pages on MSDN, the UE (doc guys) combine that with page views to focus on low rated, high viewed pages first. From: ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of djones...@gmail.commailto:djones...@gmail.com Sent: Wednesday, March 23, 2011 6:54 AM To: ozDotNet Subject: Re: Raising
Re: Raising property changed events
Thanks David. I feel much happier about my rant now. I don't usually do them, but really happy to know that it's not fallen on deaf ears. Passing it up the chain is the best thing I could hope for, short of the documentation actually being improved. :) On Thu, Mar 24, 2011 at 11:28 AM, David Kean david.k...@microsoft.comwrote: First of all, I understand your points. I also get a little frustrated by documentation in certain areas of the product (VS Extensibility docs are frustrating me at the moment) – one of the reasons that I add Community comments to the bottom of the page when I see something missing. However, despite what it looks like on the outside, documentation *is* a priority, both on the content side and infrastructure side of things (Lightweight view is a perfect example) There’s a couple of reasons why the docs are sparse, lacking examples, or just bad: 1) There’s a lot of it. .NET Framework’s surface area doubled between 3.0 and 4.0. Whether that’s a good thing or not is in the eye of the beholder, but it makes it especially hard to write good docs on all members. 2) Developers aren’t doc writers. While I do see some good XML comments written by developers internally, it’s usually a rarity – and spending time on this means less features. Less features means complaints about missing features. It’s a catch-22. 3) On some teams the doc writers don’t have a lot to do with the feature team. While not true on my team (BCL) where the doc team turns up to every spec review team meeting, other teams I’ve been on the doc writer lives in a completely separate building and doesn’t get involved until after the team is feature complete. We do need to improve on this. 4) It’s not worth the return on investment to heavily doc every single member. As mentioned below, there’s over 200,000 pages on MSDN, some with under 10 pages view *total. *We need to make sure we make the right call around what members people are having trouble with and what members need examples. However, we’re also continually updating the docs every month. For example, we recently overhauled the Stringhttp://msdn.microsoft.com/en-us/library/system.stringclass docs last year, this is despite this class practically not changing for over 5 years (I think we added a couple of methods in 4.0). Please also don’t get me wrong, I’m not trying to make excuses, but rather trying to be honest. Although I can’t directly impact the docs as a whole (other adding comments to them where I can, and making sure my feature’s docs are good) – I will forward this thread onto a couple of people who can impact them. *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Stephen Price *Sent:* Wednesday, March 23, 2011 7:26 PM *To:* ozDotNet *Subject:* Re: Raising property changed events Assuming around 200 people on the list, if we each take 1000 pages we should be able to tag them all with a please provide examples I get what you are saying we can post on the pages asking for improvement. Doesn't help you at that moment. It does show that documentation wasn't a priority. Someone wrote the code once how come that person, or someone following closely behind didn't document this public facing class/method When it was written? Going back and documenting it all now is a mammoth task. Technology is being invented at a pace faster than you can learn it, we need to be making it easier to learn not harder. Agree with Grant. This is an opportunity to really shine. On Thu, Mar 24, 2011 at 7:38 AM, Trevor Andrew tand...@tassoc.com.au wrote: David, I think that Stephen’s original rant was not that this was one example of a page documentation needing improvement, but that the entire style of the documentation is so minimal as to be close to useless. Unless I’m getting to the wrong bits, very little of the documentation I reach initially on MSDN is of any more use than confirming syntactic correctness and the most minimal explanation of the usage variation. And as Stephen pointed out, sometimes almost laughably obvious explanations of usage at that. My recollections of earlier versions were that they contained much more descriptive information, examples, guidance on the use of methods and the like. As stated below, it starts to look like Google gives broader information than MSDN does. Cheers, Trevor *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *David Kean *Sent:* Thursday, 24 March 2011 2:17 AM *To:* djones...@gmail.com; ozDotNet *Subject:* RE: Raising property changed events If you come across pages where you think the docs need improvement, please use the Rating box in the top right. Given that there’s something like 200,000+ pages on MSDN, the UE (doc guys) combine that with page views to focus on low rated, high viewed pages first
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
RE: Raising property changed events
Apparently (according to Brendon Forster :)) All the cool kids are using this.
http://code.google.com/p/notifypropertyweaver/
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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
RE: Raising property changed events
But I like using a few extension methods pulled from ReactiveUI libraries.
public static TRet RaiseAndSetIfChangedTObj, TRet(this TObj vm,
ExpressionFuncTObj, TRet property, ref TRet backingField, TRet newValue)
where TObj : ViewModelBase {
if (EqualityComparerTRet.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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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
Re: Raising property changed events
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
Re: Raising property changed events
Caliburn.Micro uses Expressions
public virtual void NotifyOfPropertyChange(string propertyName) {
if(IsNotifying)
Execute.OnUIThread(() =
RaisePropertyChangedEventCore(propertyName));
}
public virtual void
NotifyOfPropertyChangeTProperty(ExpressionFuncTProperty
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.comwrote:
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
RE: Raising property changed events
Below is not guaranteed to work, if we inline the set, GetCurrentMethod will
return the wrong method.
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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
Re: Raising property changed events
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 david.k...@microsoft.com wrote:
Below is not guaranteed to work, if we inline the set, GetCurrentMethod will
return the wrong method.
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
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
Re: Raising property changed events
On 23 March 2011 15:00, Mark Hurd markeh...@gmail.com wrote: 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. Gmail says GetCurrentMethod has /not/ been mentioned before on this mailing list since I've been part of it, so I'm remembering that wrong. Can you show an example where GetCurrentMethod does not return the expected method? This request still stands however. -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.)
Re: Raising property changed events
On Wed, Mar 23, 2011 at 3:30 PM, Mark Hurd markeh...@gmail.com wrote: 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? It's not a good approach anyway. -- Noon Silk http://dnoondt.wordpress.com/ (Noon Silk) | http://www.mirios.com.au:8081 Fancy a quantum lunch? http://www.mirios.com.au:8081/index.php?title=Quantum_Lunch Every morning when I wake up, I experience an exquisite joy — the joy of being this signature.
RE: Raising property changed events
Hmm, I'll check internally, but I'd be surprised if we give that guarantee. We're free to change our inlining policy at any time, in fact, we did just that in 3.5 SP1 x64 which broke a lot of customers who were relying on Assembly.GetExecutingAssembly() without explicitly turning off inlining for the method. Whether you can repro something now, is not a good indication of whether we'll continue to support in a future service pack or version - always check the docs. However, in saying that, the docs don't really make it clear that this might not work correctly in certain situations. In which case, if we don't give the above guarantee I'll make sure they call it out. -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Mark Hurd Sent: Tuesday, March 22, 2011 9:36 PM To: ozDotNet Subject: Re: Raising property changed events On 23 March 2011 15:00, Mark Hurd markeh...@gmail.com wrote: 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. Gmail says GetCurrentMethod has /not/ been mentioned before on this mailing list since I've been part of it, so I'm remembering that wrong. Can you show an example where GetCurrentMethod does not return the expected method? This request still stands however. -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.)
Re: Raising property changed events
GetCurrentMethod is of little use to us netcf people since it doesn't exist. In fact, I believe there is no way to get the method name in netcf for a release build. David If we can hit that bullseye, the rest of the dominoes will fall like a house of cards... checkmate! -Zapp Brannigan, Futurama On Wed, Mar 23, 2011 at 15:46, Noon Silk noonsli...@gmail.com wrote: On Wed, Mar 23, 2011 at 3:30 PM, Mark Hurd markeh...@gmail.com wrote: 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? It's not a good approach anyway. --
