Internals of Dependency Property in WPF

WPF introduces new property system to us. Every WPF objects that is inherited from DependencyObject inherently supports Dependency property containers within it. That means you can define your own dependency property in your code which can take part in some of the interesting features of WPF like Binding, Styles, Triggers, Animation, Property Inheritence etc. Today I will concentrate on how Dependency Property system is actually built and what are the benefits we get instead of using CLR property system.

Note : If you are really new in WPF and don't know about Dependency Property, it would be nice to read my post on Dependency Property or you can also try WPF Tutorial series to start on.

So lets start on using the most basic code of creating your own Dependency Property.

Writing a Reusable Custom Control in WPF

In my previous post, I have already defined how you can inherit from an existing control and define your own reusable chunk. The reusable XAML code that I have defined there is actually a composition of one of more existing elements in a common design surface. But sometimes you must define  a new behaviour for your reusable component which does not belong to any of the already existing behaviors. Custom controls can help you in this. You can define a new behaviour for your Custom control which can have a default look and feel defined for it, and obviously which can be changed using Template for the user who is using the control. In this post I am going to provide you step by step approach on defining a Custom Control for your application.

Note: If you are really new to WPF, please read my WPF Tutorial before going further. 

Steps to Create a new Custom Control

Creating a custom control is very simple. Just in your project right click and add a new Item. In the dialog box that appears, choose Custom Control template and Name it. I call it here as SimpleControl.

Once you have added the control, it adds up a new class to your project which inherits from Control. The Template also provides you with some initial help to define your own control. Lets remove all the comments for now and start building a control.

Download Sample Code

Writing a Reusable WPF Control with Design Support

Code reusablity is one of the major concern to many of us. When dealing with large projects, modularizing your project is one of the primary thing that you should look for. I have talked about many of the approaches that you can use to deal with modularizing your code, eg, Prism. In this post our intent is not to talk hard on some pattern, rather I will discuss how your WPF application supports code reusability. There are a number of approaches that WPF supports to deal with reusable component. We can use Resources to define a Resource or even use CodeBehind to write our reusable component or even load the XAML from a file using XAML Loader. Each of the approaches has its own pros and cons. Today I will show you another cool technique to write a reusable XAML for your project which will allow you to easily use Visual Studio design surface to design the component.

Note : It is a very basic article, if you want to know about details on WPF, please read my tutorial on it.

Steps to Create your Reusable Component


Lets create a series of steps to create a reusable component for your application to make it easier for you to write one yourself.

ValueType and ReferenceType : Under the Hood Part 2

Well, if you have read my previous post, you should be already clear how memory of ValueTypes and ReferenceTypes are allocated and De-allocated internally in terms of IL. Here in this post, I am going to cover some more concepts behind ValueTypes and ReferenceTypes and what exactly comprises of them.

In my previous post on the series, I have told you that any type that inherits from System.ValueTypes is stored in Stack while any type that is not inherited from System.ValueType is stored in Heap. Well, the statement is not correct totally.

ValueTypes and ReferenceTypes : Under the Hood

In .NET, Value Type and Reference Types are forms an element of confusion between both developers and the students. Many of us take this as granted that Value Types are allocated in Thread Stack ( a 1 MB local stack created per Thread) and on each method calls the local value types are allocated in the Stack such that after the call ends, the object is deallocated. On the contrary, the reference types we know are those which are always allocated in heap (which is not always true, I will discuss later) and even though they are used as locals, and will be deallocated only after an interval by a separate Thread that is running with any .NET process (called finalizer thread) which occationally starts finding the memory blocks on Heap storage and compact and store only the reachable objects called Garbage Collector. Well, in this post, I am not going to cover the details of Garbage Collection, but rather I will focus more on Value Types and Reference Types that I know personally to clear any doubt regarding them in terms of IL constructs. So after reading the post, you will know some of the basics of IL too.

Rethinking my Session on TechEd on Road

Hi Folks,

Its been a great time together on TechEd on Road event here in Kolkata. I can recollect the fun we had out of the sessions with Pinal Dave, nice to find you here Pinal and with Bijoy Singhal on Windows Phone 7. I would also like to thank Dhanajay Kumar for coming all the way from Pune only for this session, and also for giving a wonderful session to us. 

Lets now talk about my session on ".NET Fundamentals that every developers should Know". In this post I will share all the resources and source codes to make your easy way round to understand everything that you didnt understand in the session,  of course if any... :) 

Managed Extensibility Framework - A Look

Hi guys,

If you are really new to .NET framework 4.0, this is going to be a quickstart guide to a new framework for extensibility which every developers should know. In this post, I will give you a brief introduction to what Managed Extensibility Framework is all about and also create a sample application on the same.

Note: This is the basic stripped version of MEF, if you are looking for something more advanced, stay tune with my blog; its about to follow. 

Why Managed Extensibility Framework?

You can say MEF is a framework that is built on top of Reflection API, that addresses one special kind of requirement that most of the current developers are in. Modularizing an application is one of  the biggest concern for any software giant. Everyone, like me, look for some sort of plugin based modularization for their respective application and ultimately end up doing in their own way like what I did before, which ultimately does not solve the problem as someone else might end up doing the same thing little differently and eventually "my plugins cannot go into your application" kind of situation. Hence we need some sort of standardization to  address this situation such that every plugin based application can work together. MEF addresses this situation by giving you a sleek way of defining your modules as plugins and your application as a Standard host of any plugins.