Skip to main content

Posts

Showing posts from February, 2014

Building custom controls in WPF

Here I am going to briefly introduce with the types of custom controls one can build in WPF. Someone can ask why we need custom controls, if we can do everything with Styles and Control Templates ??? Well, I would say still there are scenarios where one may need custom controls. One of them can be, while creating reusable control which is composed of many other controls, i.e: I want to create a control for data entry purpose, which will take Temporary address and Permanent Address. Here I don’t want to copy/paste XAML code repeatedly for these two addresses. So, it’s better to create a one User Control and reuse it. Another scenario can be, when we need a functionality which is not provided by existing WPF controls, here custom control can be the best solution. UserControl vs Control Now before proceeding further, it is important to have a look at the two most common classes of WPF namely UserControl and Control . UserControl should be chosen when you want to combine ex

Binding Source Objects in WPF

Recently I received a request from one of the followers on ways to bind source objects. So, I thought it would be a nice topic for a post. Hence, it's here. For a binding to work, there should be a source object. The selection of source object is totally dependent on the way binding is used. If no binding source is provided, then bydefault DataContext of an element is used. The most common way is to set DataContext on parent element and let it flow to all its children. But apart from this, there are 3 other ways by which one can point to source object:  1) RelativeSource - Relative source is one of the property on a binding that can point to relative source markup extension which tells where the source can be found in hierarchy. In simple words, it is the relative path in the element hierarchy. 2) ElementName - Another way of specifying source is by using ElementName in which other element present in the current UI can be used as a source object. Here the source object

Microsoft Introduces Bing Code Search Add-On For Visual Studio

Microsoft has launched the 'Bing Code Search add-on'  for Visual Studio, representing companionship between the Bing, Visual Studio and Microsoft Research divisions. The Bing Code Search extension directly assimilates the code snippet search for C# with other languages, coming later into the Visual Studio.  As this add-on is a part of the Visual Studio, programmers will be able to use it to search for the code samples from a number of web-based repositories including MSDN, StackOverflow, Donnetperls and CSharp411. So, if you are using Microsoft Visual Studio for building apps, you can download the add-on, activate it, type the search string, press enter and you will get a couple of options that are suitable for your project.  You can grab the add-on from the Visual Studio directory page However, the add-on can be used to search for the code samples anywhere on the Web as well; Microsoft says that the sites it has shortlisted should be “more than sufficient” for most of

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.

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 iss

INotifyPropertyChanged revisited with .Net Framework 4.5

Prior to this post, I have already discussed few ways of handling INotifyPropertyChanged interface. Now you might be thinking what's next ? Well, today I'll talk about much better and cleaner way of handling this interface, which is type-safe as well as less error prone. Till now, as a common practice, we were passing a property name as a parameter of our RaisedPropertyChanged method, which unfortunately has some demerits.  Let's say, what if user changed the name of the property and forgot to change the parameter passed inside RaisedPropertyChanged method. Now you might say that we can get rid of this by using Reflection. Even I agree with that but again it comes with an additional associated cost. So, what's the solution now??? Enough of worries, this issue has been addressed in .Net 4.5, in which developer can get rid of this parameter passing approach. Impressed? An attribute titled  CallerMemberName relieves us from all the worries because now this attribut

C# 6.0 with Visual Studio 2014

Today while surfing internet, I came across a very interesting interview snippet from Anders Hejlsberg and Charles Torre, in which they talked about the future version of C#, which will be 6.0. I hope most of you are aware that .Net version shipped with Visual Studio 2013 was the minor release with numbers as 4.5.1, which was just an upgrade of version 4.5. It is expected that all the major changes will be part of .Net 5.0 which will be shipped with Visual Studio 2014. Another nice thing which came out is, C# 6.0 will be based on the new compiler Roslyn, which is written in C# itself rather than C++. We can also expect some of the very cool features of C# 6.0 as: Primary Constructors Readonly auto properties Static type using statements Property expressions Method expressions Params for enumerables Monadic null checking Constructor type parameter inference Inline declarations for out params All the probable features of C# 6.0 will make life of developers bit more eas