Showing posts with label .Net 4.5. Show all posts
Showing posts with label .Net 4.5. Show all posts

Thursday, May 29, 2014

Propagating Property Change for Static Properties

While working on any XAML based app, first thing which comes into mind is Binding. There are lot many articles on what is Binding and how it works. Don’t worry, I am not going to repeat all that stuff again. But definitely, I would like to touch upon few things which are base of my today’s write-up.

To make any property bindable or let’s say to propagate property change, we usually follow one of the below two options:
  • Implement INotifyPropertyChanged interface or
  • Create an event with name PropertyNameChanged

Point to notice here is, both the above options will work only on instance properties. Now what if my property is Static???

INotifyPropertyChanged is not going to work for static properties. None of the above options will make x:Static extension work.

What to do now ?

No worries, all these hazards can easily be overcome when you will jump to .Net 4.5.

Approach 1: Property specific static event for each and every static property
Let’s have a look at the below code:

Analysing Approach 1: Given approach will be feasible only when we have 1 or 2 static properties. If there are many static properties, then code will be bulky and un-maintainable as each property will have separate event.

Solution: Instead of writing static event for each and every static property, one generic event should be there.

Approach 2: Single Generic static event for all the static properties
Let’s have a look at the below code:

Analysing Approach 2: This approach will work very smoothly irrespective of how many static properties are present in a given class.

Point worth mentioning about EventHandler parameters:

Why null is passed as a parameter in EventHandler?
First placeholder is for passing instance. But as this is Static property, instance value will be null. 

Hope you enjoyed learning this new feature.

Saturday, February 15, 2014

Overload resolution revisited in .Net 4.5

Overload resolution has always been an area of frequent attention for compiler team. So, once again there are some major changes done to make the compiler more intelligent. Let's have a look at the below snippet(picked from MSDN) first and try to predict the output:

Output in Visual Studio 2010: ExampleMethod: p2 is object
Output in Visual Studio 2012/13: ExampleMethod: p2 is string

Explanation of code: In above code, there are two overloads with a difference of 3rd parameter params and bit a different ordering of parameters.

Visual Studio 2010 picks the overload without params parameter whereas Visual Studio 2012 compiler is smarter and picks the overload which has more specific type.

If all your overloads do precisely the same thing, then this change will not be a problem. But in other cases, it may lead to crashes or exceptions.

So, going forward, be careful while offering method overloads.

Tuesday, February 11, 2014

Named parameters revisited in .Net 4.5

As most of you are aware that there are lot of language and compiler changes has happened with recent release of .Net, but all the issues will not arise until and unless you are recompiling your code. Once you recompile your code, these changes will be introduced regardless of which framework you target.

Today I am writing about one of these breaking changes happened in .Net 4.5. 
With earlier framework, named and optional parameter concept was introduced and unfortunately it was implemented incorrectly. In essence, there was a issue with the evaluation order of named parameter and will occur only when you are using methods as an argument. 

Let's have a look at this snippet taken from MSDN:

Expected output: A C B
Output in Visual Studio 2010: C B A
Output in Visual Studio 2012/2013: A C B

Hope by this time, you are convinced about this incorrectness.  Please note, here issue is with named parameters and has nothing to do with optional parameters. This issue is with the Visual Studio 2010 compiler which is giving the unexpected results.

Reason: Incorrect results are because named parameters are evaluated before the positional arguments. For both named and positional evaluation must be from left to right. This was the bug in VS 2010 and is addressed in VS 2012.

This is unlikely to cause a problem in your code until and unless you are calling methods in your argument list.
Suggestion: Avoid calling methods in argument list if order of execution is important for your application.

Note: ref and out parameters may also suffer from side effects due to this change.