Overview

New hardware and API in the Windows 7 operating system provide applications the ability to receive input from multiple touches simultaneously. WPF enables applications to detect and respond to touch in a manner similar to responding to other input, such as the mouse or keyboard, by raising events when touch occurs.

WPF exposes two types of events when touch occurs: touch events and manipulation events. Touch events provide raw data about each finger on a touchscreen and its movement. Manipulation events interpret the input as certain actions.

Prerequisites

You need the following components to develop an application that responds to touch.

• Microsoft Visual Studio 2010.
• Windows 7.
• A device, such as a touchscreen, that supports Windows Touch.

WPF exposes two types of events when touch occurs: touch events and manipulation events. Touch events provide raw data about each finger on a touchscreen and its movement. Manipulation events interpret the input as certain actions.

Terminology

The following terms are used when touch is discussed.

• Touch is a type of user input that is recognized by Windows 7. Usually, touch is initiated by putting fingers on a touch-sensitive screen. Note that devices such as a touchpad that is common on laptop computers do not support touch if the device merely converts the finger’s position and movement as mouse input.
• Multitouch is touch that occurs from more than one point simultaneously. Windows 7 and WPF supports multitouch. Whenever touch is discussed in the documentation for WPF, the concepts apply to multitouch.
• A manipulation occurs when touch is interpreted as a physical action that is applied to an object. In WPF, manipulation events interpret input as a translation, expansion, or rotation manipulation.
• A touch device represents a device that produces touch input, such as a single finger on a touchscreen.

Controls that Respond to Touch

The following controls can be scrolled by dragging a finger across the control if it has content that is scrolled out of view.

• ComboBox
• ContextMenu
• DataGrid
• ListBox
• ListView
• MenuItem
• TextBox
• ToolBar
• TreeView

The ScrollViewer defines the ScrollViewer.PanningMode attached property that enables you to specify whether touch panning is enabled horizontally, vertically, both, or neither. The ScrollViewer.PanningDeceleration property specifies how quickly the scrolling slows down when the user lifts the finger from the touchscreen. The ScrollViewer.PanningRatio attached property specifies the ratio of scrolling offset to translate manipulation offset.

Class Diagram

Below class diagram highlights the key classes and their members for touch support:

• Touch
  • Touch events are exposed both by UIElement, UIElement3D, and ContentElement as bubbling events, and via Touch.FrameReported as application level event (to be compatible with Silverlight).
  • While touch down, move and up events are both tunneling and bubbling, touch enter and leave events are bubbling only.
  • Touch device capture is explicit via UIElement.CaptureTouch method.
  • Touch events are synchronous.
  • Touch events are always fired, whether manipulation events are fired or not.
  • WPF supports multitouch.
• Manipulation
  • Manipulation events are exposed by UIElement as bubbling event only.
  • Manipulation events are fired on an UIElement only its IsManipulationEnabled is true.
  • Manipulation events are synchronous.
  • WPF supports three types of manipulation: expansion and rotation (including single finger rotation with pivot point), and inertia.
  • Touch device capture is implicit with manipulation.
  • Static class Manipulation contains methods to get and update manipulation parameters outside of manipulation event handlers. It also contains methods for more advanced usage of manipulation logic, such as adding adding and removing manipulators. 
  • WPF supports multiple gestures.
  • WPF doesn’t support gestures, or 3D manipulation.
• ScrollViewer has built-in support for manipulation and inertia, and it is customizable by applications.

Touch

Touch Events

The base classes, UIElement, UIElement3D, and ContentElement, define events that you can subscribe to so your application will respond to touch. Touch events are useful when your application interprets touch as something other than manipulating an object. For example, an application that enables a user to draw with one or more fingers would subscribe to touch events.

All three classes define the following events, which behave similarly, regardless of the defining class.

• TouchDown
• TouchMove
• TouchUp
• TouchEnter
• TouchLeave
• PreviewTouchDown
• PreviewTouchMove
• PreviewTouchUp
• GotTouchCapture
• LostTouchCapture

Like keyboard and mouse events, the touch events are routed events. The events that begin with Preview are tunneling events and the events that begin with Touch are bubbling events. When you handle these events, you can get the position of the input, relative to any element, by calling the GetTouchPoint or GetIntermediateTouchPoints method.

The Execution Path of Touch Events

To understand the interaction among the touch events, consider the scenario where a user puts one finger on an element, moves the finger in the element, and then lifts the finger from the element. The following illustration shows the execution of the bubbling events (the tunneling events are omitted for simplicity).

The following list describes the sequence of the events in the preceding illustration.

1. The TouchEnter event occurs one time when the user puts a finger on the element.

2. The TouchDown event occurs one time.

3. The TouchMove event occurs multiple times as the user moves the finger within the element.

4. The TouchUp event occurs one time when the user lifts the finger from the element.

5. The TouchLeave event occurs one time.

   When more than two fingers are used, the events occur for each finger.

Manipulation and Inertia

Manipulation Events

For cases where an application enables a user to manipulate an object, the UIElement class defines manipulation events. Unlike the touch events that simply report the position of touch, the manipulation events report how the input can be interpreted. There are three types of manipulations, translation, expansion, and rotation. The following list describes how to invoke the three types of manipulations.

• Put a finger on an object and move the finger across the touchscreen to invoke a translation manipulation. This usually moves the object.

• Put two fingers on an object and move the fingers closer together or farther apart from one another to invoke an expansion manipulation. This usually resizes the object.

• Put two fingers on an object and rotate the fingers around each other to invoke a rotation manipulation. This usually rotates the object.

More than one type of manipulation can occur simultaneously.

When you cause objects to respond to manipulations, you can have the object appear to have inertia. This can make your objects simulate the physical world. For example, when you push a book across a table, if you push hard enough the book will continue to move after you release it. WPF enables you to simulate this behavior by raising manipulation events after the user’s fingers releases the object.

For information about how to create an application that enables the user to move, resize, and rotate an object, see Walkthrough: Creating Your First Touch Application.

The UIElement defines the following manipulation events.

• ManipulationStarting

• ManipulationStarted

• ManipulationDelta

• ManipulationInertiaStarting

• ManipulationCompleted

• ManipulationBoundaryFeedback

By default, a UIElement does not receive these manipulation events. To receive manipulation events on a UIElement, set UIElement.IsManipulationEnabled to true.

The Execution Path of Manipulation Events

Consider a scenario where a user "throws" an object. The user puts a finger on the object, moves the finger across the touchscreen for a short distance, and then lifts the finger while it is moving. The result of this is that the object will move under the user’s finger and continue to move after the user lifts the finger.

The following illustration shows the execution path of manipulation events and important information about each event.

Manipulation events

The following list describes the sequence of the events in the preceding illustration.

1. The ManipulationStarting event occurs when the user places a finger on the object. Among other things, this event allows you to set the ManipulationContainer property. In the subsequent events, the position of the manipulation will be relative to the ManipulationContainer. In events other than ManipulationStarting, this property is read-only, so the ManipulationStarting event is the only time that you can set this property.

2. The ManipulationStarted event occurs next. This event reports the origin of the manipulation.

3. The ManipulationDelta event occurs multiple times as a user’s fingers move on a touchscreen. The DeltaManipulation property of the ManipulationDeltaEventArgs class reports whether the manipulation is interpreted as movement, expansion, or translation. This is where you perform most of the work of manipulating an object.

4. The ManipulationInertiaStarting event occurs when the user’s fingers lose contact with the object. This event enables you to specify the deceleration of the manipulations during inertia. This is so your object can emulate different physical spaces or attributes if you choose. For example, suppose your application has two objects that represent items in the physical world, and one is heavier than the other. You can make the heavier object decelerate faster than the lighter object.

5. The ManipulationDelta event occurs multiple times as inertia occurs. Note that this event occurs when the user’s fingers move across the touchscreen and when WPF simulates inertia. In other words, ManipulationDelta occurs before and after the ManipulationInertiaStarting event. The ManipulationDeltaEventArgs.IsInertial property reports whether the ManipulationDelta event occurs during inertia, so you can check that property and perform different actions, depending on its value.

6. The ManipulationCompleted event occurs when the manipulation and any inertia ends. That is, after all the ManipulationDelta events occur, the ManipulationCompleted event occurs to signal that the manipulation is complete.

Boundary Feedback

The UIElement also defines the ManipulationBoundaryFeedback event. This event occurs when the ReportBoundaryFeedback method is called in the ManipulationDelta event. The ManipulationBoundaryFeedback event enables applications or components to provide visual feedback when an object hits a boundary. For example, the Window class handles the ManipulationBoundaryFeedback event to cause the window to slightly move when its edge is encountered.

Mouse Promotion

You can cancel the manipulation by calling the Cancel method on the event arguments in any manipulation event except ManipulationBoundaryFeedback event. When you call Cancel, the manipulation events are no longer raised and mouse events occur for touch. The following table describes the relationship between the time the manipulation is canceled and the mouse events that occur.

The event that Cancel is called in	The mouse events that occur for input that already occurred
ManipulationStarting and ManipulationStarted	Mouse down events.
ManipulationDelta	Mouse down and mouse move events.
ManipulationInertiaStarting and ManipulationCompleted	Mouse down, mouse move, and mouse up events.

Note that if you call Cancel when the manipulation is in inertia, the method returns false and the input does not raise mouse events.

The Relationship Between Touch and Manipulation Events

A UIElement can always receive touch events. When the IsManipulationEnabled property is set to true, a UIElement can receive both touch and manipulation events. If the TouchDown event is not handled (that is, the Handled property is false), the manipulation logic captures the touch to the element and generates the manipulation events. If the Handled property is set to true in the TouchDown event, the manipulation logic does not generate manipulation events. The following illustration shows the relationship between touch events and manipulation events.

Touch and manipulation events

The following list describes the relationship between the touch and manipulation events that is shown in the preceding illustration.

• When the first touch device generates a TouchDown event on a UIElement, the manipulation logic calls the CaptureTouch method, which generates the GotTouchCapture event.

• When the GotTouchCapture occurs, the manipulation logic calls the Manipulation.AddManipulator method, which generates the ManipulationStarting event.

• When the TouchMove events occur, the manipulation logic generates the ManipulationDelta events that occur before the ManipulationInertiaStarting event.

• When the last touch device on the element raises the TouchUp event, the manipulation logic generates the ManipulationInertiaStarting event.

EventArgs Class Diagram

Below class diagram shows all the touch and manipulation EventArgs classes and relevant types.

Dependency property is a major innovation of WPF. A dependency property has the same simple and familiar programming interface as a CLR property, but allows its value to be dynamically decided/changed by many factors, like other properties, styles, templates, data-binding, animation, element composition, class inheritance etc, and can be implemented to provide self-contained default value, validation, coercion and eventing logic. Silverlight implements a subset of the WPF property system functions, so there are significant differences between WPF and Silverlight. Straight porting between WPF and Silverlight may not be possible, major source code changes may be required. This three-part post series will use a simple example to demonstrate the common pattern of implementing dependency property on WPF and Silverlight, the difference between the two property systems and how to port from one to another, and then use the NumericUpDown control I wrote for Silverlight Toolkit to demonstrate how complex and tricky dependency property can get on Silverlight. I will only focus on validation, coercion and change handling in this series. When I find time, I may write on other aspects of dependency properties.

WPF Dependency Property Overview

MSDN has good Dependency Property Overview, so I will just call out the three core classes and two important sets of methods of the programming interface of WPF property system:

• DependencyProperty, which provides properties like Name, OwnerType, PropertyType, and methods like Register, RegisterAttached, RegiterReadOnly, RegisterAttachedReadOnly:

  [TypeConverter("System.Windows.Markup.DependencyPropertyConverter, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null"), ValueSerializer(typeof(DependencyPropertyValueSerializer))]
  public sealed class DependencyProperty
  {
      // Fields
      public static readonly object UnsetValue;
  
      // Methods
      public DependencyProperty AddOwner(Type ownerType);
      public DependencyProperty AddOwner(Type ownerType, PropertyMetadata typeMetadata);
      public override int GetHashCode();
      public PropertyMetadata GetMetadata(Type forType);
      public PropertyMetadata GetMetadata(DependencyObject dependencyObject);
      public PropertyMetadata GetMetadata(DependencyObjectType dependencyObjectType);
      public bool IsValidType(object value);
      public bool IsValidValue(object value);
      public void OverrideMetadata(Type forType, PropertyMetadata typeMetadata);
      public void OverrideMetadata(Type forType, PropertyMetadata typeMetadata, DependencyPropertyKey key);
      public static DependencyProperty Register(string name, Type propertyType, Type ownerType);
      public static DependencyProperty Register(string name, Type propertyType, Type ownerType, PropertyMetadata typeMetadata);
      public static DependencyProperty Register(string name, Type propertyType, Type ownerType, PropertyMetadata typeMetadata, ValidateValueCallback validateValueCallback);
      public static DependencyProperty RegisterAttached(string name, Type propertyType, Type ownerType);
      public static DependencyProperty RegisterAttached(string name, Type propertyType, Type ownerType, PropertyMetadata defaultMetadata);
      public static DependencyProperty RegisterAttached(string name, Type propertyType, Type ownerType, PropertyMetadata defaultMetadata, ValidateValueCallback validateValueCallback);
      public static DependencyPropertyKey RegisterAttachedReadOnly(string name, Type propertyType, Type ownerType, PropertyMetadata defaultMetadata);
      public static DependencyPropertyKey RegisterAttachedReadOnly(string name, Type propertyType, Type ownerType, PropertyMetadata defaultMetadata, ValidateValueCallback validateValueCallback);
      public static DependencyPropertyKey RegisterReadOnly(string name, Type propertyType, Type ownerType, PropertyMetadata typeMetadata);
      public static DependencyPropertyKey RegisterReadOnly(string name, Type propertyType, Type ownerType, PropertyMetadata typeMetadata, ValidateValueCallback validateValueCallback);
      public override string ToString();
  
      // Properties
      public PropertyMetadata DefaultMetadata { get; }
      public int GlobalIndex { get; }
      public string Name { get; }
      public Type OwnerType { get; }
      public Type PropertyType { get; }
      public bool ReadOnly { get; }
      public ValidateValueCallback ValidateValueCallback { get; }
  }

  
  
• DependencyObject, which provides methods like GetValue, SetValue, ReadLocalValue, CoerceValue, ClearValue to access/modify the value of a dependency property: 

  [TypeDescriptionProvider(typeof(DependencyObjectProvider)), NameScopeProperty("NameScope", typeof(NameScope))]
  public class DependencyObject : DispatcherObject
  {
      // Methods
      public DependencyObject();
      public void ClearValue(DependencyProperty dp);
      public void ClearValue(DependencyPropertyKey key);
      public void CoerceValue(DependencyProperty dp);
      public sealed override bool Equals(object obj);
      public sealed override int GetHashCode();
      public LocalValueEnumerator GetLocalValueEnumerator();
      public object GetValue(DependencyProperty dp);
      public void InvalidateProperty(DependencyProperty dp);
      protected virtual void OnPropertyChanged(DependencyPropertyChangedEventArgs e);
      public object ReadLocalValue(DependencyProperty dp);
      public void SetCurrentValue(DependencyProperty dp, object value);
      public void SetValue(DependencyProperty dp, object value);
      public void SetValue(DependencyPropertyKey key, object value);
  
      // Properties
      public DependencyObjectType DependencyObjectType { get; }
      internal uint EffectiveValuesCount { [FriendAccessAllowed] get; private set; }
      public bool IsSealed { get; }
  }

  
  
• PropertyMetadata, which allows the default value, coercion and change handling logic to be specified during dependency property registration: 

  public class PropertyMetadata
  {
      // Methods
      public PropertyMetadata();
      public PropertyMetadata(object defaultValue);
      public PropertyMetadata(PropertyChangedCallback propertyChangedCallback);
      public PropertyMetadata(object defaultValue, PropertyChangedCallback propertyChangedCallback);
      public PropertyMetadata(object defaultValue, PropertyChangedCallback propertyChangedCallback, CoerceValueCallback coerceValueCallback);
      protected virtual void Merge(PropertyMetadata baseMetadata, DependencyProperty dp);
      protected virtual void OnApply(DependencyProperty dp, Type targetType);
  
      // Properties
      public CoerceValueCallback CoerceValueCallback { get; set; }
      public object DefaultValue { get; set; }
      protected bool IsSealed { get; }
      public PropertyChangedCallback PropertyChangedCallback { get; set; }
  }

  
  
• DependencyProperty.Register* methods and their overloads
• PropertyMetadata constructors

Example

The example below has a simple class MyButton, which inherits from Button class and implements a dependency property MyValue. The value of MyValue property must be between 0 to 10, enforced by its validation logic IsValidMyValue(). The effective value of MyValue property depends on its default value(0), user input (set request parameter), and the value of its IsEnabled property inherited from base class. The last dependency is implemented by coercion logic CoerceMyValue and dependency change event handler OnIsEnabledChanged(). Overall the implementation of MyValue demonstrates the common pattern of dependent property on WPF:

• CLR wrapper: public int MyValue { get; set; }
• Dependency property identifier: public static readonly DependencyProeprty MyValueProperty
• Registration with property system: DependencyProperty.Register()
• Validation logic: IsValidMyValue static method
• Coercion logic: CoerceMyValue static method

It is common and advised to also implement changed handling logic via:

• PropertyChangedCallback OnMyValueChanged static method
• protected virtual void OnMyValueChanged(oldValue, newValue) to raise the changed event, and for subclass to override
• public static readonly RoutedEvent MyValueChangedEvent routed event identifier and event registration
• public event RoutedPropertyChangedEventHandler<int> MyValueChanged event for client

Below is source code of the example:

• Window1.xaml:

  <Window x:Class="WpfApp1.Window1"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      xmlns:my="clr-namespace:WpfApp1"
      Title="Window1" Height="300" Width="300">
      <StackPanel>
          <my:MyButton x:Name="mybtn" Content="MyButton" 
                       MyValueChanged="mybtn_MyValueChanged" Click="mybtn_Click"/>
      </StackPanel>
  </Window>

• Window1.xaml.cs:

  using System;
  using System.Windows;
  using System.Windows.Controls;
  namespace WpfApp1
  {
      // sample class to demonstrate how to implement a DependencyProperty 
      public class MyButton : Button
      {
          // DP: CLR wrapper
          public int MyValue
          {
              get { return (int)GetValue(MyValueProperty); }
              set { SetValue(MyValueProperty, value); }
          }
          // DP: dependency property identifier & registration
          public static readonly DependencyProperty MyValueProperty =
              DependencyProperty.Register(
                  "MyValue", typeof(int), typeof(MyButton),
                  new PropertyMetadata(0,
                      new PropertyChangedCallback(OnMyValueChanged),
                      new CoerceValueCallback(CoerceMyValue)),
                  new ValidateValueCallback(IsValidMyValue));
          // DP: validation callback
          private static bool IsValidMyValue(object value)
          {
              int newValue = (int)value;
              return newValue >= 0 && newValue <= 10;
          }
          // DP: coercion callback
          private static object CoerceMyValue(DependencyObject d, object value)
          {
              MyButton ctrl = (MyButton)d;
              int newValue = (int)value;
              return ctrl.IsEnabled ? Math.Min(5, newValue) : Math.Max(6, newValue);
          }
          // DP: changed callback
          private static void OnMyValueChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
          {
              MyButton ctrl = (MyButton)d;
              int oldValue = (int)e.OldValue;
              int newValue = (int)e.NewValue;
              ctrl.OnMyValueChanged(oldValue, newValue);
          }
          // RE: changed event identifier & registration
          public static readonly RoutedEvent MyValueChangedEvent =
              EventManager.RegisterRoutedEvent("MyValueChanged", RoutingStrategy.Bubble,
                  typeof(RoutedPropertyChangedEventHandler<int>), typeof(MyButton));
          // RE: changed event
          public event RoutedPropertyChangedEventHandler<int> MyValueChanged;
          // RE: use a protected virtual to raise event
          protected virtual void OnMyValueChanged(int oldValue, int newValue)
          {
              RoutedPropertyChangedEventArgs<int> e =
                  new RoutedPropertyChangedEventArgs<int>(oldValue, newValue);
              e.RoutedEvent = MyValueChangedEvent;
              RaiseEvent(e);
          }
          // DP: event handler to trigger re-calculation of MyValue because of dependency change
          private static void OnIsEnabledChanged(object sender, DependencyPropertyChangedEventArgs e)
          {
              MyButton ctrl = (MyButton)sender;
              ctrl.CoerceValue(MyButton.MyValueProperty);
          }
          public MyButton()
          {
              IsEnabledChanged += OnIsEnabledChanged;
          }
      }
      /// <summary>
      /// Interaction logic for Window1.xaml
      /// </summary>
      public partial class Window1 : Window
      {
          public Window1()
          {
              InitializeComponent();
          }
          private void mybtn_Click(object sender, RoutedEventArgs e)
          {
          }
          private void mybtn_MyValueChanged(object sender, RoutedPropertyChangedEventArgs<int> e)
          {
              int oldValue = e.OldValue;
              int newValue = e.NewValue;
          }
      }
  }

How Dependency Property Work on WPF

To demonstrate how dependency property works on WPF, I set a break point on most functions, and used the Immediate debug window to check values and change states.

Registration

• When the program starts, DependencyProperty.Register is executed, which in turn calls IsValidMyValue to validate the default value 0:
  
  

Effective Value

Click on the MyButton instance to trigger the break point on mybtn_Click event handler, then use the Immediate window to check on MyValue property. As shown below:

• Even though mybtn.MyValue isn’t assigned any value, it has an effective value of 0, the default value of this dependency property, as shown by results of mybtn.MyValue and mybtn.GetValue.
• It is important that the CLR wrapper and GetValue/SetValue calls should always have the same effect. This is done by the CLR wrappers being just a wrapper for GetValue/SetValue and nothing more.
• mybtn.ReadLocalValue(MyButton.MyValueProperty) results shows that there is no local storage for MyValue property on mybtn instance.
• When mybtn.MyValue takes initial value, there is no change notification, as OnMyValueChanged isn’t called at program start.

  

Validation

In Immediate window, set mybtn.MyValue to an invalid value -1 by typing in command "mybtn.MyValue = -1":

• The CLR wrapper is called, which in turn calls SetValue, which triggers validation on the new value -1.
  
  
• IsValidMyValue returns false on the new value -1, WPF property system then throws ArgumentException:
  
  
• Check the value of MyValue via three ways: CLR wrapper, GetValue, ReadLocalValue: nothing changed. This is important, since on Silverlight state does change, even for invalid set operation, so we have to write code to restore the state, as I will show in part two of the series.
  
  

Coercion

Again in Immediate window, try set mybtn.MyValue to 8, which is valid, but because mybtn.IsEnabled is true, the effective value must be less than or equal to 5:

• First, validation is called on the new value 8, via CLR wrapper and SetValue:
  
  
• IsValidMyValue(8) returns true, so coercion logic CoerceMyValue is called, via CLR wrapper, SetValue, UpdateEffectiveValue, and ProcessCoerceValue:
  
   
• CoerceMyValue(8) returns a different value 5, so WPF property system calls IsValidMyvalue on the coerced effective value 5:
  
  
• IsValidMyValue(5) returns true, so WPF property system calls changed logic OnMyValueChanged, with oldValue as 0 and newValue as 5. Both values are effective values, since there was no old value in mybtn instance, and the new value is actually 8. OnMyValueChanged in turns call its proctected virtual version, which raises MyValueChanged routed event, and executes MyValueChanged event handlers, if there is any. 
  
• Check the value of MyValue property: both CLR wrapper and GetValue return the new effective value 5, but GetLocalValue returns 8, remembering the original user request. This is very important, as we will see next.
  
  

Dynamic Re-calculation as Dependency Changes

Now let’s set mybtn.IsEnabled to false in Immediate window. This changes one of the dependencies for MyValue, which should trigger re-calculation of the effective value of MyValue property, if I have coded it right (and I did, of course :

• First, please note that IsEnabled change processing is synchronous, i.e., OnIsEnabledChanged is called before "mybtn.IsEnabled = false" returns. This is important since IsEnabled change handling is asynchronous on Silverlight.
• We have to trigger the recalculation since the property system doesn’t know MyValue depends on IsEnabled. This is done by handling IsEnabledChanged event (IsEnabledChanged += OnIsEnabledChanged in MyButton()) and call CoerceValue from inside OnIsEnabledChanged event handler.
• CoerceValue in trun calls UpdateEffectiveValue, ProcessCoerceValue, and then our coercion logic CoerceMyValue. Please note that CoerceMyValue is called with newValue of 8, not the current effective value 5. The original set request parameter 8 is remembered by mybtn instance locally, as shown by ReadLocalValue result before. This is important, since Silverlight doesn’t do this, which makes implementing coercion very tricky, as will be shown in part 3 of the blog series with bugs in Silverlight RangeBase and its subclasses like Slider and ScrollBar.
  
  
• Since mybtn.IsEnabled is now false, the originally requested value 8 becomes valid, so CoerceMyValue returns 8.
• 8 is different from previous effective value of 5, so UpdateEffectieValue calls NotifyPropertyChange, which ultimately calls our changed logic OnMyValueChanged with oldValue of 5 and newValue of 8. This happens even though there is no new set operation for MyValue property. It is the IsEnabled dependency change that caused MyValue effective value change, which in turns triggers change notification and event handling for MyValue property, and this is all happening synchronously.
  
  
• After the coercion, change notification, and event handling finishes, check the value of MyValue property: now all three methods (mybtn.MyValue, mybtn.GetValue, mybtn.ReadLocalValue) return the same result.
  
  
• one last experiment: type mybtn.ClearValue(MyButton.MyValueProperty) in Immediate window to clear the local value (8) of the dependency property, which in turn triggers change handling logic OnMyValueChanged, with newValue of 0, the new effective value derived from MyValue’s default property.
  
  

Conclusion

As we can see from above example and experiment, WPF has a powerful property system, which makes both implementing and using dependency properties very easy. It is a lot trickier on Silverlight though, because Silverlight only implements a subset of WPF functionality. In part two of the post series, I will re-implement above example on Silverlight, and demonstrate the difference between WPF and Silverlight. In part three, I will use RangeBase and NumericUpDown to demonstrate the gotcha on Silverlight, which is the original motivation for this post series. Stay tuned!

PS: the first post of the series ended up a lot longer and more time consuming than I expected, so I will stop here. If there is enough interest, I can upload the project for you to experiment, and a code snippet that provides most of the plumbing for implementing dependency property on WPF. Thanks!