– Manual

  – Old

  – New

Recall that WPF fits into the view paradigm of the MVC.  Therefore, do notget “validating WPF” confused with “validating my business logic rules.”  For the purposes of a good design, yes, you should include validation in your domain layer as well.

Manual method

With the manual method, we see ourselves performing value checking in the Property setter and raising an exception if there is a problem.  For example

public string Name {   get{return _name;}  set {      if(value == null)         {             throw new ArgumentNullException();          }         _name = value; }

Don’t do the above.  Supposing that your WPF Textbox, or any other UserControl, was bound to the Name property, then you would never see the exception.  WPF binding ignores exceptions!

2.  Old Method

The old method takes us back to the early days of HTML forms and javascript.  The algorithm is thus:

• On Button click, manually (in terms of writing inline code) check the values of all the parameters you wish to parse.
• If they are good.
  • Parse input data. Submit.
• Else
  • Generate a custom error message.
  • Display the custom error message.
  • Return.

Now anyone that has ever done any manual validation in ASP.NET will realize that the above is painful, when compared to using the validation utility classes (such as the RegularExpressionValidator).  This takes us to the 3rd method.

 3.0 New Method

The new method allows us to (1)put the display logic of the validation error straight in the XAML(2) keep high cohesion by separating our validation into separate classes, and (3) allows us to reuse validation logic across multiple UserControls.

The new method is composed of creating your own ValidationRule. From there you simply (1) mention the validation rule in your data binding, and (2) define a style for how to display the error.  This page has a nice example on how to do this (near the bottom).

Sometimes there will be a warning in the output window complaining about a broken binding and sometimes not.

Diagnoses

Binding just is not working.  Syntax looks correct but it simply will not hook together

1. Check that in the .xaml file, that the binding is has an ElementName=_this in it.  You will also need to define _this in the UserControl heading.
   1. Eg. <UserControl …

*Namespace_imports*

x:Name=_this>

Binding is firing but nothing is happening

1. Check you are calling NotifyPropertyChanged properly, with the correct name inside of the arguments (e.g. that “MyProperty” is spelled correctly in

PropertyChanged(this, new PropertyChangedEventArgs(“MyProperty”));

Using a non-gui thread to update a user control (and thus fire a binding)

1. Read up on BeginInvoke (which is asynchronous) or Invoke (which is synchronous) if calling a GUI a method or property of a user control in the code behind.    Quite frankly, a non-gui thread is not allowed to do modify the above.  You may be catching the exception and never hearing about it.

Binding worked for awhile but stopped (e.g. click a radio button fired a binding, but no longer)

1. Check that the object you are binding to in the code behind is initialized, so that it is not null, prior to InitializeComponent() being run;  If this is not possible (for a variety of reasons this may not be possible), then consider using a Dependency Property.
2. Check that a style isn’t clobbering your binding.  WPF only likes to apply one style to a component (note that you can combine multiple styles by creating one that is based on another).  If you have a binding declared on a component and then there is another style, you may notice that once a binding fires in your style, that the binding declared outside of the style no longer fires.

InitializeComponent() is usually called within the in the default constructor of a WIndow or UserControl.

It essentially “loads and initializes” the user controls contained within the XAML.

For example, if you have

XAML:

<Button x:Name=”_myButton” />

CodeBehind:

// Comments.

_myBUtton will be null until after InitializeComponent() is called. After you call InitializeComponent, you will be free to cal things on the button, such as _myBUtton.COntent=”Press me” (however, do not call that prior to InitializeComponent() or things will crash.

Notes Regarding Binding and InitializeComponent:

Using NotifyPropertyChanged to binding to objects in your code behind

• Ensure that all of your objects in your code behind are initialized (e.g. not null) prior to calling InitializeComponent(), otherwise your bindings will fail and not work properly (even if you initialize the objects you are binding to after the call to InitializeComponent)

Using DependencyProperties as objects to bind to in your code behind

• Code behind objects do not need to be initialized prior to InitializeComponent call.  You can initialize objects which you are binding to after the InitializeComponent call and the bindings will pick up and work properly (however, using DependencyProperties is more cumbersome)

Example:

Problem:

Everything will work fine and dandy under the radio button is clicked  (or activated via the space bar) You see, clicking the radio button automatically causes it to be checked, regardless of the value that IsChecked is bound to, so when this disparity happens, the checkbox will no longer care about what it is bound to.

Rules

• UnderylyingValue = true => RadioButton checked
• UnderylyingValue = false => RadioButton unchecked
• Radio button is clicked on => Binding value is ignored
• Radio button has space bar pressed on it => Binding value is ignored

Maybe styles? Nope

You could say “aha problem with the binding mechanisms” and move the binding into a style, which would use DataTriggers to listen to UnderlyingValue and then changed IsChecked appropriately; but alas, this will also fail, just like the above, once the radio button is clicked.

Solution:

We want to prevent the binding from being broken upon UI input; specifically, prevent it from being broken from (1) mouse click and (2) space bar press,  while not moving the solution into the code behind as that is poor design.

To do this, we’ll leverage RoutedEvents.  We will

1. Capture the Mouse click and space bar events before the radio button itself gets to see the event
2. Make necessary changes and mark event as handled

Capturing the mouse and space bar event before radio button…

Make necessary changes and mark event as handled

And we’re done.

Clicking or space bar causes our event handlers to fire, which change the property which our radio button is bound to and then the event is eaten.  The radio button is updated to reflect the state of the property we just changed, and the binding isn’t broken since the radio button never changes it’s IsChecked state as a result of the click or space bar press