Brace yourself, interview is coming!

Nowadays IT is more in focus than ever, news are full with hopeless firms, crave experts. But this is not a recruiter blog, so I just skip this part and lets focus on the technical stuff :) Regardless of your work experiences, before you go to an interview reread the basics and learn the technologies you may missed in the last years. 

Here are some sites as starting points:

• General C#
• Basic and advanced tutorials
• WPF
• WCF
• MVC

Target platforms: Any CPU vs x86 vs x64

A lot of developers misinterpret the meaning of "Target platform" option in Visual Studio. You can read a good explanation here. I don't want to take credit for others work, so I just summarize the 5 most important facts:

• "Any CPU, means that the assembly will run natively on the CPU is it currently running on.", however "Any CPU does not guarantee that it will run on both 32-bit and 64-bit Windows." (if it has 32-bit dependencies, but not marked - author)
• "[...] this setting actually does not affect the build of the assembly in any way except to set the platform status information on the assembly’s CLR header."
• "Reasons to set your project as x86 include dependencies upon native DLLs that are only available in 32-bit"
• "[...] assemblies marked for x86 can still run on 64-bit Windows."
• "All assemblies targeting .Net 1.0 and 1.1 will be 32-bit only (x86) [...]"

Don't forget to read the whole article to have a better understanding :)

The differece between "new" and "override"

However the keyword new and the keyword override are very alike, they have some really different purpose and it is not recommended to swap / mix them. You can read their behaviors and purposes e.g. on StackOverflow. 

Here is an example for the article above. As you can see, you will have different result, which can cause you some headache if you try to find a bug.

   public class Base
   {
      public virtual void Method()
      {
         Debug.WriteLine("Base");
      }
   }

   public class Override : Base
   {
      public override void Method()
      {
         Debug.WriteLine("Override");
      }
   }

   public class New : Base 
   {
      public new void Method()
      {
         Debug.WriteLine("New");
      }
   }

   public class Program
   {
      public Program()
      {
         var b = new Base();
         b.Method(); // "Base"

         b = new Override();
         b.Method(); // "Override"
         
         b = new New();
         b.Method(); // "Base"
      }

      static void Main(string[] args)
      {
         var p = new Program();
      }
   }

Unfortunately C# compiler has a really bad behavior and let you to hide a method without explicitly write new. Ohh, yeah... you will get a warning, but not a compile error nor a runtime error. All you are going to face with, is some unwanted misbehavior. So, watch out.

ReactiveUI extension for WPF

My very first article got published in the Dot-Net-Pro magazine last week under the title "Haben Sie schon reagiert?". It is about a new WPF extension: ReactiveUI, which lets you to develop event based, always responding and up to date UI in WPF. You don't need to worry about INotifyPropertyChanged, BackgroundWorker or CommandManager anymore. 

The greatest thanks go to my colleague, Hendrik Lösch, for his support.

Windows 7 WPF style on Windows XP / 8 / 8.1

The issue

If you have a few years experience, than you already faced with the issue probably: WPF style looks different on different Windows'. You develop and design something on Windows 7, but some old-fashion customer still have Windows XP or maybe already installed the brand new Windows 8.1 and everything falls apart. You can prevent it when you use your own style, custom controls and redefine every single style property. Well, it does not sound too friendly. But don't worry, there is another option.

Why is it different in the first place?

Although the .NET runtime framework has the same version, somehow it still looks different on different OSs due the default style on Windows XP is Luna, on Windows 7 is Aero (first introduced in Vista) and on Windows 8 / 8.1 is Aero2 (or Aero Glass). If you create a WPF application and don't change the theme, references or create custom styles then one of those themes will be applied respectively to the OS Version.
On one hand it is a little bit annoying, since one does not want to create a complete custom style for an intern-used-only application just to make sure progressbars and comoboxes as well as word wrapping  are the same. On the other hand it has to be this way to make sure OS design is consistent. So, whenever your application is gonna need the PresentationFramework.dll, the current OS will provide it's own default.

Solution

The solution is easier than you think. You don't need to customize any control or use 3rd party stuff. All you need is to tell your app to use e.g the Aero theme. First copy the Windows 7 Aero DLLs (PresentationCore.dll, PresentationFramework.dll, PresentationFramework.Aero.dll) to your solution folder from c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\ and then explicit reference them into your solution. After that, modify your App.xaml and include the theme as resource. Enjoy :)

<Application x:Class="WPFAeroDemo.App"

             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

             StartupUri="MainWindow.xaml">

    <Application.Resources>

        <ResourceDictionary>

            <ResourceDictionary.MergedDictionaries>

                <ResourceDictionary Source="/PresentationFramework.Aero;component/themes/Aero.NormalColor.xaml"/>

            </ResourceDictionary.MergedDictionaries>

        </ResourceDictionary>

    </Application.Resources>

</Application>

Result

Without explicit theme definition

OS Default style on Windows XP (left), on Windows 7 (middle) and on Windows 8.1 (right)

With explicit definition

Aero style on Windows XP (left), on Windows 7 (middle) and Windows 8.1 (right)

How to implement a login screen in WPF

I recently needed to implement an application with login screen and googled some best practice, but without luck. I've seen some solutions, but none of them could impress me. So, I decided to do it in my way and share with you.

First of all, my prerequisites were not to use two windows, because it looks lame when WPF closes one window and starts a new one. I also didn't want to use Popups or modal dialogs because they come after main window and they are part of the it. Furthermore main window (UserControl) will be loaded, initialized and rendered before you even see a login screen. If you don't put to much logic in your constructor it might be fast, but still unwanted at that moment. So, I think the best way is to use one Window with two UserControls.

Let's start with the contents, we need a LoginViewModel and a MainViewModel. Login will be shown first and if the credentials were accepted screen will be changed to main. Create a common interface, IFrameContent with an OnChangeRequest event handler member. Implement this interface as a FrameContent base class.

public abstract class FrameContent : ViewModelBase, IFrameContent
{
   public event EventHandler OnChangeRequested;
   
   protected void Deactivate()
   {
      if (this.CanDeactivated())
      {
         var handler = OnChangeRequested;
         if (handler != null)
         {
            handler(this, EventArgs.Empty);
         }
      }
   }

   public virtual bool CanDeactivated()
   {
      return true;
   }

}      

Not a big deal. ViewModelBase is a simple base class, which implement INotifyPropertyChanged. Okay, inherit this class and create our two screens: main and login.

public class LoginViewModel : FrameContent
{      
   public RelayCommand LoginCommand { get; private set; }

   public LoginViewModel()
   {
      this.LoginCommand = new RelayCommand(Login, (p) => true);
   }

   private void Login(object parameter)
   {
      this.Deactivate();
   }
}

MainViewModel is the same story. RelayCommand is an implemented ICommand interface. In the view bind the command to a button. What here happens is a command execution without any check. But don't worry, you can extend it later.

Finally create the FrameWindow, our only window and put everything together. Create two properties for our two view models and an extra for currently selected. Subscribe their events and in the handler change to the other content.

public class FrameWindowViewModel : ViewModelBase
{
   private LoginViewModel _Login;
   private LoginViewModel Login
   {
      get
      {
         if (this._Login == null)
         {
            this._Login = new LoginViewModel();
            this._Login.OnChangeRequested += Login_LoginSuccessful;
         }

         return this._Login;
      }
   }

   private MainViewModel _Main;
   private MainViewModel Main
   {
      get
      {
         if (this._Main == null)
         {
            this._Main = new MainViewModel();
            this._Main.OnChangeRequested += Main_OnChangeRequested;
         }

         return this._Main;
      }
   }

   private IFrameContent _currentContent;
   public IFrameContent CurrentContent
   {
      get
      {
         return this._currentContent;
      }
      private set
      {
         this._currentContent = value;
         this.RaisePropertyChanged("CurrentContent");
      }
   }

   public FrameWindowViewModel()
   {         
      this.ChangeContent(this.Login);
   }

   private void Main_OnChangeRequested(object sender, EventArgs e)
   {
      ChangeContent(this.Login);
   }

   private void Login_LoginSuccessful(object sender, EventArgs e)
   {
      ChangeContent(this.Main);     
   }

   private bool ChangeContent(IFrameContent content)
   {
     this.CurrentContent = content;

     return true;
   }
}

The trick is, that you need to bind the CurrentContent in the view as a ContentPrestener's content.

<Window x:Class="LoginDemoClient.Views.FrameWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Demo client" Height="350" Width="525">

    <ContentPresenter Grid.Row="1" Content="{Binding CurrentContent}" />

</Window>

Override the CanDeactivated() method in content classes and build in some real check to prevent login in case of invalid credentials.

Of course you can (need to) extended bases classes with OnActivated(), OnDeactivated() etc methods in a real application, but the base concept does not change. You have one current content and change it in a frame window (SRP) without those two actually would known each other or without EventBus or EventAggregator (which are anti-pattern in my opinion).

You can download a full source code from here.

MDI implemention in WPF

I just recently noticed that, there is no MDI (Multiple Document Interface) support in WPF. Microsoft recommends to use TabControl or AvalonDock. However sometimes it could be really useful to see multiple documents in the same time, e.g: during data process. So I decided to develop a one. You can download MDIContainer from here. There is a sample application as well.

How to start

After you downloaded the binary (PDB is also attached), all you need to do is add MDIContainer.Control.dll as reference in your WPF Application. In order to use you need at least .NET 4. MDIContainer does not need any third party or additional references.

Hello MDI

You can decide to use direct content or bind ItemsSource to container. However direct content does not make too much sense. Why do you need closable windows if you have fixed content? So, let's stay by binding. 

<MDI:MDIContainer Margin="4" ItemsSource="{Binding Items}">
    <MDI:MDIContainer.Resources>
        <Style TargetType="{x:Type MDI:MDIWindow}">
            <Setter Property="Title" Value="{Binding Title}" />             
        </Style>
    </MDI:MDIContainer.Resources>
</MDI:MDIContainer>

As you can see, it is similar to the implementation of a TabControl. ItemsSource is also not magic, a simple ObservableCollection<IContent>. You don't have to use IContent interface if you don't want to, you can put there object or your class. It doesn't matter. I prefer to use interfaces in situations like this, to make it more flexible.

public ObservableCollection<IContent> Items { get; private set; }

public interface IContent
{
   string Title { get; }
}

There is only one thing left, a user control. Like I wrote, there is no limitation. Create a user control with a view model like you want. Here is a really sample one:

public class PersonWindow : ViewModelBase, IContent
{
  public string Title { get; private set; }

  public PersonWindow(string title)
  {
    this.Title = title;
  }
}

If you don't know how to implement ViewModelBase or what could it be, you can read more here. Currently you can leave it's view empty, but don't forget to set it as DataContext or DataTemplate.

Back to the main window's view model, where you defined the Items. Initialize the Items and add some content:

public MainWindowViewModel()
{
  this.Items = new ObservableCollection<IContent>();
  this.Items.Add(new PersonWindow("Window 1");
  this.Items.Add(new PersonWindow("Window 2");
  this.Items.Add(new PersonWindow("Window 3");
}

Of course this tiny little example does not make too much sense, but shows you how simple to use this control.

You can check it's CodePlex site and download a fully working demo with source code.

How to subscribe on property changes without events

In my previous post I already explained how to implement INotifyPropertyChanged and INotifyPropertyChanging properly. At least one proper way. If you missed it, you might want to read it before this post, because this one based heavily on it. Let’s assume we want to use it as base class for our ViewModels and Models as well. In our really simple example we have a model called Person. This class is inherited from our base ViewModel (implemented in my prev. post), named  ViewModelBase.

public class Person : ViewModelBase
{
   private string _name;
   public string Name
   {
     get { return _name; }
     set { this.SetAndRaisePropertyChanged(() => this.Name, ref _name, value); }
   }

   private DateTime _birthDate;
   public string BirthDate
   {
     get { return _birthDate; }
     set { this.SetAndRaisePropertyChanged(() => this.BirthDate, ref _birthDate, value); }
   }
}

And a 'manager' class, our MainViewModel, also inherited from ViewModelBase. Person is bound to UI, user can create a new one, modify and existing one, it doesn't matter. Anything happens with our class Person we want to receive a notification in our MainViewModel. We can extend our base class with an OnPropertyChanged protected method, like OnPropertyChanging, but those are protected and we are in another class. We can use the PropertyChanged event, but there are two issues with it: first it is a hard reference, we need to manage subscriptions (subscribe and unsubscribe), otherwise the garbage collector (GC) won't dispose our class. Second issue: we'll get every PropertyChanged event only with a property name. So we had to check every time, whether this property is our property using 'magic' string. Furthermore we always had to keep it in our heads, when we rename or refactor a property we also need to change those compare strings. So, might be working, but not a good idea. Something similar would be nice:

this.SubscribeOnPropertyChanged(() => this.Person, p => p.Name, OnNameChanged);

Ok, let's see how to achieve this. Create a new method in our ViewModelBase class. First a class selector (which is actually a property or field of our MainViewModel), then a property selector for the selected class, and an Action to execute in case of any changes. The trick is: we pick the class and store it in our external Action reference collection.

private readonly List<PropertySubscription> OnChangedActions = 

    new List<PropertySubscription>();

protected void SubscribeOnPropertyChanged<TClass, TProperty>(

    Expression<Func<TClass>> classSelector, 

    Expression<Func<TClass, TProperty>> propertySelector, Action onPropertyChanged)
   where TClass : ViewModelBase
{
   var propertyName = ExtractPropertyName(propertySelector.Body as MemberExpression);
   var targetClass = classSelector.Compile();

   targetClass().OnChangedActions.Add( 

       new PropertySubscription(propertyName, onPropertyChanged));
}

PropertySubscription is really just a metaclass to store external subscriptions. You can use a simply KeyValuePair<string, Action> instead. To avoid redundant code, ExtractPropertyName must be extracted into two methods. Simply create a new method with the same name and copy the last few lines from the original one into the new one:

private string ExtractPropertyName(MemberExpression me)
{
   if ((me != null) && !string.IsNullOrEmpty(me.Member.Name))
   {
      return me.Member.Name;
   }

   throw new ArgumentException("Property could not be found.");
}

Ok, so we store it, but it does not do anything. We need to execute those actions whenever a property change occurs. Create a method which filters our collection on property name and execute every subscription action. Don't forget to store actions into a local variable inside the iteration to avoid "Access to modified closure".

private void ExecuteExternalSubcriptions(string propertyName)
{
   var actions = this.OnChangedActions.Where(s => s.PropertyName == propertyName);

   foreach (var action in actions)
   {
      var local = action;
      if (local.OnChangedAction != null)
      {
         local.OnChangedAction();
      }
   }
}

There is only one step left, add this method to our RaisePropertyChanged method. The new one is something like:

private void RaisePropertyChanged(string propertyName)
{
   var handler = this.PropertyChanged;
   if (handler != null)
   {
      handler(this, new PropertyChangedEventArgs(propertyName));
   }

   this.ExecuteExternalSubcriptions(propertyName);
}

From now on, every time a property has been changed, we also check external subscriptions and if we found any, execute them after property changed event. Thanks to this little extension in the ViewModelBase we can easily execute custom actions outside our class without strong references. Since we reference in a (probably) short living class to a long living class GC can dispose our object or class without problem. Furthermore developing is also much better and easier, working with expressions does not let us to compile with typo and we can refactor or rename our properties without to worry about magic strings in our code.

I can't believe you are still reading :) To appreciate your patient I give you one more thing: subscriptions to any property change. As you can see, our previous method allows us to subscribe to one particular property change. But sometimes we need all of them. Subscribing to all of them would be silly, so let's just add one more method, without property selector.

private readonly object dummy = new object();

protected void SubscribeOnPropertyChanged<TClass>(

    Expression<Func<TClass>> classSelector, Action onPropertyChanged)
   where TClass : ViewModelBase
{
   this.SubscribeOnPropertyChanged(classSelector, x => x.dummy, onPropertyChanged);
}

But what is 'dummy and why? Like I said before, I really hate to build logic on strings, but to keep our code simply and effective we want to use the same collection. But our collection stores PropertySubscriptions, where property name is obligatory. Best way is to create a private field and use it as property in our subscription. What we need it filter out this property before we iterate through our actions. So, let's change our ExecuteExternalSubscriptions method:

private void ExecuteExternalSubscriptions(string propertyName)
{
   var actions = this.OnChangedActions.Where(

       s => s.PropertyName == propertyName || 

       s.PropertyName == this.ExtractPropertyName(() => this.dummy));

   foreach (var action in actions)
   {
      var local = action;
      if (local.OnChangedAction != null)
      {
         local.OnChangedAction();
      }
   }
}

And how it works? Here is a tiny code snippet:

public class MainWindowViewModel : ViewModelBase
{      
  private Person Person = new Person();

  public MainWindowViewModel()
  {
   // to subscribe on Person's name changes
   this.SubscribeOnPropertyChanged(() => this.Person, p => p.Name, OnNameChanged);

   // to subscribe on any property changes in Person clsas
   this.SubscribeOnPropertyChanged(() => this.Person, OnPersonChanged);
  }

  private void OnNameChanged()
  { }

  private void OnPersonChanged()
  { }
}

CodeProject

Event extension

To send notification from one class to an other Event is the best way. But to avoid exceptions we need to check it every time whether it is null or not. It isn't a big deal but a few extra lines every time you want to fire an event, and with every line you write in your code also incrase the possibility of a bug. So, why not an extension method?

public static class EventExtensions
{
   public static void RaiseEvent(this EventHandler handler, object sender, EventArgs e)
   {
      var local = handler;
      if (local != null)
      {
         local(sender, e);
      }
   }
}

Sooo easy. Store handler into a local variable to avoid "Access to modified closure" issue and simply fire an event, if it is not null. In practice it would be something like this:

public class SampleClass
{      
   private event EventHandler CustomEvent;

   public SampleClass()
   {
      this.CustomEvent.RaiseEvent(this, EventArgs.Empty);
   }
}

One simple line instead of five and any changes you might need to make in your application requires to change only one simple extension method. What do I mean? For example log every event.

CodeProject

Extend the INotifyPropertyChanged implemenation with a shorter setter

When a WPF application is needed, than probably a noticeable percentage of the code is property declaration, due MVVM, at least in the UI / client layer or in the contracts. Event with the method mentioned in one of my previous post the implementation costs 6-12 lines depends on how you break lines. After some testing I found a better way, a more elegant way to set a property value. However the LOC won't be less and the execution time will be increased it is also an option.
Stick to my old ViewModelBase class (if you don't know what I mean, you definitely have to read my previous post) let's extend it with a read only field to cache class Fields and initialize it in the constructor. It is Lazy because you don't necessary need it, only if the new SetAndRaisePropertyChanged is gonna be used.

private readonly Lazy<IEnumerable<FieldInfo>> Fields;

protected ViewModelBase()
{
  this.Fields = new Lazy<IEnumerable<FieldInfo>>(() => 

      this.GetType().GetFields(

          System.Reflection.BindingFlags.NonPublic | 

          System.Reflection.BindingFlags.Public | 

          System.Reflection.BindingFlags.Instance));
}

My goal was to define a method with only one parameter (the value). So, what I need is to figure out the property and the backing field. Since I use .NET4 [CallerMethodName] is not an option. But the StrackFrame and StrackTrace are always there.

private string ConvertPropertyNameToBackingField(string propertyName)
{
   return "_" + propertyName;
}

protected bool SetAndRaisePropertyChanged<TProperty>(TProperty value)
{
   var method = new StackFrame(1).GetMethod();
   if (method != null && method.Name.StartsWith("set_"))
   { 
      var propertyName = method.Name.Substring(4);
      var field = this.Fields.Value.SingleOrDefault(f => 

         f.Name == this.ConvertPropertyNameToBackingField(propertyName));

      if (field != null)
      {
         var oldValue = field.GetValue(this);
         var result = oldValue == null || oldValue.Equals(value) == false;

         if (result)
         {
            this.OnPropertyChangingHandler(propertyName, oldValue, value);

            field.SetValue(this, value);

            this.RaisePropertyChanged(propertyName);                  
         }

      return result;
      }

      throw new ArgumentException("Could not find backing field: " + 

          this.ConvertPropertyNameToBackingField(propertyName) + 

          " in class " + this.GetType().Name);
   }

   throw new InvalidOperationException(@"Simplified SetAndRaisePropertyChanged method 

     cannot be used outside of the property setter. In this case consider 

     to use the another overload with three parameters.");
}

And the usage?

private string _MyProperty;
public string MyProperty
{
   get { return _MyProperty; }
   set { this.SetAndRaisePropertyChanged(value); }
}

Peace of cake, isn't it? As you can see, it only works if you call it from the setter and there is some kind of naming convention.

And what are the numbers?

The very first setter calls in the ViewModel do not show a big differences. In case of 3 parameters it takes around 0.0015 seconds, while this one takes 0.002. Real differences are during 2nd, 3rd, 4th etc. call. With property selector, it only costs 0.00008, but this one needs around 0.0007, so factor ten. But if you really need performance you should consider to use the string version (without property selector).

CodeProject

How to implement INotifyPropertyChanging

I think anyone, who at least once developed a WPF application, has also met the INotifyPropertyChanged interface. It is the key to build a program based on MVVM pattern, it helps to refresh binding and keep UI and code behind sync. Just like its name says, you receive a notification after a property's value has changed. But what if you need a notification before it changes? Let's assume we want to track user's changes and rollback if it is needed. In this case the INotifyPropertyChanging interface has to be implemented. Unfortunately, however this interface exists in .NET, nothing supports it. It means, you don't get any update or notify during property changing. But it doesn't have to mean, that you can't implement it yourself. So, let's see:

First, INotifyPropertyChanged.

protected void RaisePropertyChanged(string propertyName)
{
  var handler = this.PropertyChanged;
  if (handler != null)
  {
    handler(this, new PropertyChangedEventArgs(propertyName));
  }
}

I don't really like to operate with 'magic' strings, furthermore you don't get any compile error, but runtime error in case of typo, which is quite irritating. So, make it private and create another one with property selector using Expression.

protected void RaisePropertyChanged<TProperty>(Expression<Func<TProperty>> propertySelector)
{
  var property = this.ExtractPropertyName(propertySelector);
  this.RaisePropertyChanged(property);
}

private string ExtractPropertyName<TProperty>(Expression<Func<TProperty>> propertySelector)
{
  MemberExpression me = propertySelector.Body as MemberExpression;
  if (me == null)
  {
    UnaryExpression ue = propertySelector.Body as UnaryExpression;
    if (ue != null)
    {
       me = ue.Operand as MemberExpression;
    }
  }

  if ((me != null) && !string.IsNullOrEmpty(me.Member.Name))
  {
    return me.Member.Name;
  }

  throw new ArgumentException("Property could not be found.");
}

Alright. So far so good. But it would be better, if we hadn't write in every property setter a value compare, a backing field setter and a raise. We can use a SetAndRaisePropertyChanged method instead. It has three parameters: a property selector expression, a backing field reference and the value itself. If the value really changed, we set it and raise a property change.

protected bool SetAndRaisePropertyChanged<TProperty>(

    Expression<Func<TProperty>> propertySelector, 

    ref TProperty backingField, TProperty value)
{
  var result = backingField == null || backingField.Equals(value) == false;

  if (result)
  {
    var propertyName = this.ExtractPropertyName(propertySelector);          
    backingField = value;          
    this.RaisePropertyChanged(propertyName);
  }

  return result;
}

In this moment, it wouldn't be necessary to explicitly extract the property name, but it make sense later. So, we have a base class, which provides a SetAndRaisePropertyChanged method. With this method you can implement a bindable property like this:

private string _myProperty;
public string MyProperty
{
   get { return _myProperty; }
   set { this.SetAndRaisePropertyChanged(() => this.MyProperty, ref _myProperty, value); }
}

Ok, after this little detour let's start to implement the INotifyPropertyChanging interface. You can add to your base class or not, it's up to you, has no effect after all. Our goal is, to receive a notification before a property actually changes. Create an empty generic virtual method, it can be overwritten in the inherited class to handle property changing. As the method signature shows, you get the property name, the old value and the new value as well.

protected virtual void OnPropertyChanging<TProperty>(

    string propertyName, TProperty oldValue, TProperty newValue)
{ }

You cannot cancel or prevent the change, at least not at this point. I assume the base class also implements the INotifyPropertyChanging interface and you have a PropertyChanging event, too. In this case:

private void OnPropertyChangingHandler<TProperty>( 

    string propertyName, TProperty oldValue, TProperty newValue)
{
   var hander = this.PropertyChanging;
   if (hander != null)
   {
      hander(this, new PropertyChangingEventArgs(propertyName));
   }

   // call virtual method after event
   this.OnPropertyChanging(propertyName, oldValue, newValue);
}

If not, you can simply remove the event handler part from the method. To make it work, add this handler method to the SetAndRaisePropertyChanged, right before backing field setter line. As result the new content of your method looks like this:

protected bool SetAndRaisePropertyChanged<TProperty>(

    Expression<Func<TProperty>> propertySelector, 

    ref TProperty backingField, TProperty value)
{
   var result = backingField == null || backingField.Equals(value) == false;

   if (result)
   {
      var propertyName = this.ExtractPropertyName(propertySelector);
      // call changing method
      this.OnPropertyChangingHandler(propertyName, backingField, value);
      backingField = value;
      this.RaisePropertyChanged(propertyName);
   }

   return result;
}

And that's it. All you need to do is inherit your class from this base class, use SetAndRaisePropertyChanged instead of explicitly comparing and setting value and overwrite OnPropertyChanging method. Like I mentioned before, you can't prevent value changes. The problem is that if property is bound to a visual element (e.g TextBox), the user already made changes, you receive any notification first in code behind after that. So, if you want to prevent it, you actually need to set it back to it's old value, but sometimes it is so late. Other issue can be a complex control, like a TabControl. If you try to prevent tab changes you might face with some inconsistency. The same page is visible, but an other tab header is selected.

CodeProject

Make your code better and faster

Some best practice solution to help to improve your code quality and - in given case - make it faster as well. A lot of small things can make your life easier, help to maintain your code and prevent possible bugs. So, lets jump in:

.Any() or .Length instead of Count()

In case of IEnumerable the content will be evaluated lazy, so try do it as late as possible. If you need to check whether an IEnumerable is empty or not always use .Any() == true instead of .Count() > 0. Why? For .Any() it is enough to find the first item, but for .Count() you need to go through the whole list. In case of high cardinal it can take a while. In the following two code snippets hasValue has the same result, both in the first case much faster. If it is not IEnumerable but an Array[] then .Length > 0 is even more faster then .Any() since it does not start any iteration.

// stops after the first item
var hasValue = myEnumerable.Any();

// iterate through
var hasValue = myEnumaerable.Count() > 0;

Access to Modified Closure

It is more like a bug than a best practice. There is no other way to do it. If you use ReSharper you probably have seen this warning before. Working with delegates in an iteration can be dangerous. Store them in a local variable before using them.

Typical mistake:

foreach (var tab in this.TabItems)
{
  tab.CustomCommand = new RelayCommand(() => 
      { 
        Debug.WriteLine(tab.Header);       
      });     
}

Because it will be evaluated later, when CustomCommand executes, every tab will produce the same output. How to fix it? Store tab.Header in a local variable.

foreach (var tab in this.TabItems)
{
  var header = tab.Header;
  tab.CustomCommand = new RelayCommand(() => 
      { 
        Debug.WriteLine(header);       
      });     
}

Event handling

Similar to the point mentioned above. Between event was fired and subscription was made can a lot of thing happening. Save the handler before use it.

var handler = this.CustomEventHandler;
if (handler != null)
{
  handler(this, EventArgs.Empty);
}

One exit point

This is more like a religion. My personal opinion is: one method one return. Means, do not return a result in the middle of the method. Especially do not break a void method. Makes extreme difficult to follow the code or to debug, furthermore the maintenance is also more difficult.

Try to avoid:

public void MyMethod()
{
  // do not use, negate the if statement instead
  if (someBooleanField == false)
  {
    return;
  }

  switch (someEnumField)
  {
    // don't
    case enumValue1: 
         return;
    case enumValue2:
         i+= 5;
         break;
  }
}

In case of logging or debugging it is much easier to add one line before the return statement instead of changing every return path. Something like this:

public string MyMethod(bool param)
{
  var result = string.Empty;
  
  if (param != false)
  {
    switch (this.MyEnum)
    {
      case EnumMember1: 
         result = "result string";
         break;
      case EnumMember2:
         result = "second";
         break;
    }
  }

  return result;
}

 

Do not use the exclamation mark (!)

Looks cool, make code shorter, but really easy to misread. Not a big deal to write == false and you saved yourself some headache next morning after checking in.

// you can read it, but can you do it at 9 AM, before your coffee? :)
if (!this.MyProperty && !(this.MyBoolean || this.MyBoolean2))
{ }

// a little bit better
if (this.MyProperty == false && (this.MyBoolean || this.MyBoolean2) == false)
{ }

And in the first case one "delete" or "backspace" can change the entire functionality without a compile error, in the second case, it is not gonna happening.

Outsourcing and the power of base classes

If your method is more than 30-50 lines, than you either dealing with some complex logic or you forgot to outsource. When you have more methods you can easily reuse them instead of (re)implementing it. Implementing a function twice (not in the same class, but in the whole solution!!!!) should cause some reconsideration: "is it really good enough?". But, when it comes to the third time, you definitely need to change your code.

Put common codes in base (abstract) classes, don't afraid to use them, they help to keep your code organized and help to avoid multiple implementations, too.

Evaluation order

Like I mentioned before, try to evaluate only when it's really needed. When you need to do some if-else statement put the fastens condition first and the slowest and the end. C# evaluates conditions in the given order and stop if the value is determined. So

if (this.MyBool == false && this.MyEnumerable.Any() && this.Validate(this) == false)
{ }

When MyBool is true, C# breaks and jumps into the else (if there is any) and does not evaluate MyEnumerable nor Validate the complete view model. You can save a lot of execution time.

Document your code smart

There a lot of tool, addin or 3rd party solution for documenting VS code. They try to figure out the the functionality from the name of methods, properties etc. Actually, I don't think they would be useful at any point. You're gonna end up generating meaningless documentation for every line of code. Let's see an example:

/// <summary>
/// Gets a value indicating whether is read only.
/// </summary>
public bool IsReadOnly { get; private set; }

/// <summary>
/// The Result
/// </summary>
private CustomResult Result;

/// <summary>
/// The my method
/// </summary>
private void MyMethod()
{ }

Every method, property, field is documented. But total meaningless, like this MSDN documentation. I guess you've already knew IsReadOnly gets or sets something, but what is it? How to make it better in your code? Document only public properties, methods and interfaces. Private fields, properties are for internal use only. Add some comment if it's needed. Unfortunately there is no document inheritance in VS, but it's enough to document virtual members once, where you define them.

/// <summary>
/// Is the complete page read only
/// </summary>
public bool IsReadOnly { get; private set; }

private CustomResult Result;

// do some internal calculation before proceed
private void MyMethod()
{ }

Isn't it better and faster? Actually if your naming convention good enough you have done half of the documentation task, the code documents itself. Some guidelines can be found on the MSDN Naming Guidelines site.