Monthly Archives: November 2014

Automatically update a WPF Popup position

I wanted a means to automatically reposition a popup in relation to it’s placement target – for example I created a popup that was displayed to the right of another control (the placement target), but when the control’s parent window moved the popup (by default) does not move with it – I needed it to reposition in relation to the placement target.

So I’ve implemented the following behavior to automatically reposition the popup when the parent window is moved

public class AutoRepositionPopupBehavior : Behavior<Popup>
{
   private const int WM_MOVING = 0x0216;

   // should be moved to a helper class
   private DependencyObject GetTopmostParent(DependencyObject element)
   {
      var current = element;
      var result = element;

      while (current != null)
      {
         result = current;
         current = (current is Visual || current is Visual3D) ? 
            VisualTreeHelper.GetParent(current) :
            LogicalTreeHelper.GetParent(current);
      }
      return result;
   }

   protected override void OnAttached()
   {
      base.OnAttached();

      AssociatedObject.Loaded += (sender, e) =>
      {
         var root = GetTopmostParent(AssociatedObject.PlacementTarget) as Window;
         if (root != null)
         {
            var helper = new WindowInteropHelper(root);
            var hwndSource = HwndSource.FromHwnd(helper.Handle);
            if (hwndSource != null)
            {
               hwndSource.AddHook(HwndMessageHook);
            }
         }
      };
   }

   private IntPtr HwndMessageHook(IntPtr hWnd, 
           int msg, IntPtr wParam, 
           IntPtr lParam, ref bool bHandled)
   {
      if (msg == WM_MOVING)
      {
         Update();				
      }
      return IntPtr.Zero;
   }

   public void Update()
   {
      // force the popup to update it's position
      var mode = AssociatedObject.Placement;
      AssociatedObject.Placement = PlacementMode.Relative;
      AssociatedObject.Placement = mode;
   }
}

So to use the above code we simple use the following XAML within a popup element

<i:Interaction.Behaviors>
   <behaviors:AutoRepositionPopupBehavior />
</i:Interaction.Behaviors>

When the AssociatedObject is loaded we locate the topmost window hosting the AssociatedObject and then we hook into the message queue watching for the Window WM_MOVEING message. On each WM_MOVEING message, we update the placement of the popup. To get the Popup to recalculate its position we need to change the placement to something other than what it’s set as, i.e. it needs to change. Then when we reset the placement to our original placement, the Popup position is recalculated.

This code could be improved by checking the Placement and ensuring it changes – in the code above I simply set to PlacementMode.Relative because I know my code a different PlacementMode. Also the above code does not handle the Popup repositioning in the PlacementRectangle is used. Also my requirement doesn’t include the resizing of the PlacementTarget.

I’ll leave those changes until I need them…

Update

Seems I did need to handle resizing of the PlacementTarget so I’ve now added the following to the OnAttached method

AssociatedObject.LayoutUpdated += (sender, e) => Update();

and that appears to solve that problem.

Using the ultrasound sensor HC SR04

My first foray into Ardunio programming is to implement a robot based upon the Arduino Motor shield and some sensors – starting with the HC SR04.

In this case I want a sensor that will tell me the distance from objects, so hopefully the robot will not go around smashing into walls etc. This is where the HC SR04 comes in.

The HC SR04 has four pins. We simply connect the VCC pin to the 5V pin on the Arduino, the GND to the Arduino’s ground pin and then we’re left with two other pins.

The trigger and echo pins are digital pins, the idea being we send a 10 microsecond pulse to the trigger pin and the module will send back (via the echo pin) a value whose duration we can use to calculate the distance “pinged”. But we don’t just read the digital pin, we instead use the pulseIn function.

I’m indebted to others who have kindly supplied information on how to program this sensor, I’ve added references at the bottom of this post. I’m writing this post simply to detail the steps and code I successfully used to get this working. The referenced posts are definitely the best posts for full information on this sensor, hardware connections and code.

Here’s a simple C++ class (header and source) for handling this sensor

#ifndef _ULTRASOUND_h
#define _ULTRASOUND_h

#if defined(ARDUINO) && ARDUINO >= 100
   #include "Arduino.h"
#else
   #include "WProgram.h"
#endif

class Ultrasound
{
private:
	int triggerPin;
	int echoPin;

public:

	void init(int tiggerPin, int echoPin);
	long ping();
};

#endif

and the corresponding source

#include "Ultrasound.h"

void Ultrasound::init(int triggerPin, int echoPin)
{
   this->triggerPin = triggerPin;
   this->echoPin = echoPin;

   pinMode(triggerPin, OUTPUT);
   pinMode(echoPin, INPUT);
}

long Ultrasound::ping()
{
   digitalWrite(triggerPin, LOW);
   delayMicroseconds(2);
   digitalWrite(triggerPin, HIGH);
   delayMicroseconds(10);
   digitalWrite(triggerPin, LOW);

   long duration = pulseIn(echoPin, HIGH);
   long distance = (duration / 2) / 29.1;
   // >= 200 or <= 0 are error values, or out of range
   return distance >= 200 || distance <= 0 ? -1 : distance;
}

References

Ultrasonic Ranging Module HC – SR04
Simple Arduino and HC-SR04 Example
Complete Guide for Ultrasonic Sensor HC-SR04

Getting started with the Arduino

Let’s get started with some basics using the Arduino.

Note: I am using the Arduino Uno, so references to the specification of the Arduino should be taken as specific to the Uno.

The Arduino is programmed using C/C++ and includes libraries which make programming simple and programming the Arduino even simpler. Arduino programs are known as sketches.

My aim in this post in not to repeat everything in the excellent Arduino documentation but to just show code snippets (Arduino sketches) to simply demonstrate the principles of getting started programming the Arduino.

The Basics

Whether using the Arduino IDE/application or the Visual Micro for Visual Studio (or any other editor) and Arduino application requires at the bare minimum a setup function and a loop function, which are simply written as

void setup()
{
   // your setup goes here 
}

void loop()
{
   // your code goes here 
}

The setup as the name suggests, is used to initialize variables or set pin modes (discussed later) etc. The Arduino calls the setup and then the loop.

An Arduino is single threaded, the loop is where we add our “main” code. Of course we can create further functions that are called from the loop. Just remember when the loop function exits, the Arduino will call the function again and so on.

Input/Output

The Arduino microcontroller has digital input/outputs and analog input pins. There are no analog output pins but we can simulate such output using PWM.

Digital pins

Digital pins can be configured as either inputs or outputs. Digital pins 1 to 13 are available for input/output with digital pins marked with the tilde ~ on the Uno being pins capable of PWM and therefore simulating analog output.

By default, digital pins are inputs, but within the setup we can change them to outputs. Let’s take a look at how we do this

const int inputPin = 1;
const int outputPin = 3;

void setup()
{
   pinMode(inputPin, INPUT); // setting a digital pin for INPUT
   pinMode(outputPin, OUTPUT); // setting a digital pin for OUTPUT
}

Once the pins have been setup for I/O we need a way to read/write data from/to those pins.

Note: I will discuss using digital pins for PWM in the Analog section

Let’s look at the code to read and write to the digital pins

int value;

void loop()
{
   value = digitalRead(inputPin);
   digitalWrite(outputPin, value);
}

Digital values are HIGH and LOW (think ON and OFF), so a digitalRead will return either HIGH or LOW and likewise the digitalWrite can write a HIGH or LOW.

One thing to note is that when the pins are used for input they’re in a “high impedance state”, for us programmers this basically means that small changes can change the pin from LOW to HIGH or vice versa, and more importantly it means that if they have nothng connected to them and we’re reading their state we will get random changes in the pin state as they pick up “noise”. See Arduino General Purpose Input & Output (GPIO) Pins Explained for more on this subject.

Analog

As stated previous, there are no analog output pins, but we can use the digital pins as output pins and using PWM simulate analog output.

First off let’s take a look at the Arduino Uno and you’ll see 6 Analog input pins, marked A0 to A5. To read from the analog pins we simple use the analogRead method, for example

int value;

void setup()
{
   value = analogRead(0);
}

Analog input voltages range from 0 to 5V which results in an integer value from 0 to 1023. However when outputting analog values we can only write values 0 to 255.

We can use the map function to scale the values from input to output if we need to, i.e.

int value = map(inputValue, 0, 1023, 0, 255); 

As mentioned, we cannot write analog data to analog pins but we can write data to digital PWM pins. The Arduino library kindly gives us a function analogWrite which handles everything for us, we just need to specify one of the PWM pins for output, for example

const int outputPin = 3;

void setup()
{
   pinMode(outputPin, OUTPUT);
}

int value = 0;

void loop()
{
   if (value > 255)
      value = 0;

   analogWrite(outputPin, value++);
   delay(1000);
}

Serial I/O

We can use the UART via the Serial functions to communicate with other devices, for example intercommunication between the Arduino and a connected PC.

In such a case you might use the Serial functions to write debug information and within the Arduino IDE you can monitor the connected COM port and view the debug output.

To setup and use the Serial port we can use the following code (from the Arduino)

void setup()
{
   Serial.begin(9600);
}

void loop()
{
   if (value > 255)
      value = 0;

   Serial.println(value);
   value++;

   delay(1000);
}

With the above code, if we view the output in the serial port monitor we’ll simply see the value variable slowly (with a 1 second delay between each iteration) increase until it reaches 1024 and then it’s reset to 0.

So, we can output to the COM port but the Arduino can also read input from the COM port and thus we can create two way communications between the Arduino and another device.

For example

const int outputPin = 3;

void setup()
{
   Serial.begin(57600);
}

int value = 0;

void loop()
{
   if (Serial.available() > 0)
   {
      value = Serial.parseInt();
      if (value < 0)
         value = 0;
   }
   Serial.println(value);

   analogWrite(outputPin, value);
}

In the above code we use the parseInt method instead of the read method. The parseInt method simply takes the input and converts to an integer, so for example if using the serial port monitor within the Arduino IDE, sending 0 will result in the ASCII value (or 49) being received by the Arduino – parseInt converts this to an integer for us.

References

There are many excellent resources on the Arduino, some of which I have referenced for this post, others I will add here because they may be of use.

The Arduino Uno
Introduction to the Arduino Board
Arduino Quick Reference
Arduino Uno Schematic

WPF Adorners

An Adorner is a way of extending controls, generally by adding visual cues (or extra functionality). For example a visual cue might be adding drag and drop visuals when users try to drag and drop data onto a control or maybe we want to add resizing handles to controls within some form of UI design surface.

We can implement much of the same sort of visual cues and/or functionality by override the ControlTemplate or subclassing a control, but the Adorner offers a way to associate these cues/functionality to any type of control.

One example Adorner you may have seen is the validation UI whereby we see a red border around a control when validation fails and ofcourse we can extend this UI further if we wish.

Let’s take a look at how we might implement such an Adorner and use it.

Adorner

We’re going to start with a very simple Adorner which simply displays a little red triangle on a control – similar to the way Excel would when a note is attached to a cell.

Firstly, we need to create an Adorner. We subclass the Adorner class and supply a constructor which takes a UIElement, which is the element to be adorned.

public class NoteAdorner : Adorner
{
   public NoteAdorner(UIElement adornedElement) : 
      base(adornedElement)
   {
   }
}

This Adorner isn’t of much use. There’s nothing to see. So let’s write some code so that the Adorner displays our little red triangle over the AdornedElement. Remember that this is a layer on top of the AdorndedElement, in this case we’ll not do anything directly to the AdornedElement directly such as you might when handling drag and drop or the likes.

So add the following to the above class

protected override void OnRender(DrawingContext drawingContext)
{
   var adornedElementRect = new Rect(AdornedElement.RenderSize);

   const int SIZE = 10;

   var right = adornedElementRect.Right;
   var left = right - SIZE;
   var top = adornedElementRect.Top;
   var bottom = adornedElementRect.Bottom - SIZE;

   var segments = new[]
   {
      new LineSegment(new Point(left, top), true), 
      new LineSegment(new Point(right, bottom), true),
      new LineSegment(new Point(right, top), true)
   };

   var figure = new PathFigure(new Point(left, top), segments, true);
   var geometry = new PathGeometry(new[] { figure });
   drawingContext.DrawGeometry(Brushes.Red, null, geometry);
}

To apply an Adorner we need to write some code.

If you create a simple WPF application with a TextBox within it, and assuming the TextBox is named NoteTextBox, then we might write in the code behind of the Window class hosting the TextBox control

public MainWindow()
{
   InitializeComponent();

   Loaded += (sender, args) =>
   {
      var adorner = AdornerLayer.GetAdornerLayer(NoteTextBox);
      adorner.Add(new NoteAdorner(NoteTextBox));
   };
}

Note: It’s important to note that if you try and call the GetAdornerLayer on the TextBox before the controls are loaded you will get a null returned and thus cannot apply the adorner. So we need to apply it after the controls are loaded

In the above code we get the AdornerLayer for a control, in this case the TextBox named NoteTextBox, we then add the adorner to it.

If you run the above code you’ll get the triangle displayed over the top of the TextBox control.

One thing you may notice is that, if click on and the Adorned control it will not get focus. The Adorner ofcourse sits atop the AdornedControl and by default will not give focus to the underlying control. Basically we’ve added this control as an overlay to the AdornedElement, so ofcourse its higher in the z-order.

To change this behaviour we can alter the constructor of the NoteAdorner to the following

public NoteAdorner(UIElement adornedElement) : 
   base(adornedElement)
{
   IsHitTestVisible = false;
}

With the IsHitTestVisible set to false you can click on the Adorner UI and the AdornedElement will take focus.

As you’ll have noticed, the way to attach an Adorner is using code, this doesn’t fit so well with the idea of using XAML for such things, i.e. for a designer to handle such adornments. There are several examples on the web of ways to make adorners XAML friendly.

I’m going to implement a very simple attached property class to handle this. Which I’ve listed below

public class AttachedAdorner
{
   public static readonly DependencyProperty AdornerProperty = 
      DependencyProperty.RegisterAttached(
         "Adorner", typeof (Type), typeof (AttachedAdorner), 
         new FrameworkPropertyMetadata(default(Type), PropertyChangedCallback));

   private static void PropertyChangedCallback(
      DependencyObject dependencyObject, 
      DependencyPropertyChangedEventArgs dependencyPropertyChangedEventArgs)
   {
      var frameworkElement = dependencyObject as FrameworkElement;
      if (frameworkElement != null)
      {
         frameworkElement.Loaded += Loaded;
      }
   }

   private static void Loaded(object sender, RoutedEventArgs e)
   {
      var frameworkElement = sender as FrameworkElement;
      if (frameworkElement != null)
      {
         var adorner = Activator.CreateInstance(
            GetAdorner(frameworkElement), 
            frameworkElement) as Adorner;
         if(adorner != null)
         {
            var adornerLayer = AdornerLayer.GetAdornerLayer(frameworkElement);
            adornerLayer.Add(adorner);
         }
      }
   }

   public static void SetAdorner(DependencyObject element, Type value)
   {
      element.SetValue(AdornerProperty, value);
   }

   public static Type GetAdorner(DependencyObject element)
   {
      return (Type)element.GetValue(AdornerProperty);
   }
}

And now let’s see how this might be used

<TextBox Text="Hello World" local:AttachedAdorner.Adorner="{x:Type local:NoteAdorner}" />

AdornerLayer and the AdornerDecorator

As discussed (above) – we need to get the get the adorner layer for example AdornerLayer.GetAdornerLayer(NoteTextBox) to add our adorner to. When GetAdornerLayer is called on a Visual object, the code traverses up the visual tree (starting with the supplied UIElement) looking for an Adorner layer. Then returns the first one it finds. Hence if you write your own custom control you will need to explcitly add a place holder on the ControlTemplate denoting where any adorner should be displayed – in other words where you want the adorner layer is.

So for writing our own custom control we need to put in a place holder, the place holder is an AdornerDecorator object

<AdornerDecorator>
   <ContentControl x:Name="PART_Input" />
</AdornerDecorator>

This can only contain a single child element, although ofcourse this element can contain multiple elements that can be adorned. The AdornerDecorator specifies the position of the AdornerLayer within the visual tree.

Custom Binding MarkupExtension

In my previous post MarkupExtension revisited I looked at creating a replacement “Binding” MarkupExtension.

As usual, after posting that I decided to make some changes.

Basically I wanted to create a base class which will allow me to easily create a Binding style MarkupExtension and then the subclass need only worry about the specifics for what it’s going to do. So I present the BindingBaseExtension class.

[MarkupExtensionReturnType(typeof(object))]
public abstract class BindingBaseExtension : MarkupExtension
{
   protected BindingBaseExtension()
   {			
   }

   protected BindingBaseExtension(PropertyPath path)
   {
      Path = path;
   }

   [ConstructorArgument("path")]
   public PropertyPath Path { get; set; }

   public IValueConverter Converter { get; set; }
   public object ConverterParameter { get; set; }
   public string ElementName { get; set; }
   public RelativeSource RelativeSource { get; set; }
   public object Source { get; set; }
   public bool ValidatesOnDataErrors { get; set; }  
   public bool ValidatesOnExceptions { get; set; }
   [TypeConverter(typeof(CultureInfoIetfLanguageTagConverter))]
   public CultureInfo ConverterCulture { get; set; }

   public override object ProvideValue(IServiceProvider serviceProvider)
   {
      var pvt = serviceProvider.GetService(typeof(IProvideValueTarget)) as IProvideValueTarget;
      if (pvt == null)
         return null;

      var targetObject = pvt.TargetObject as DependencyObject;
      if (targetObject == null)
         return null;

      var targetProperty = pvt.TargetProperty as DependencyProperty;
      if (targetProperty == null)
         return null;

      var binding = new Binding
      {
         Path = Path,
         Converter = Converter,
         ConverterCulture = ConverterCulture,
         ConverterParameter = ConverterParameter,
         ValidatesOnDataErrors = ValidatesOnDataErrors,
         ValidatesOnExceptions = ValidatesOnExceptions,
         Mode = BindingMode.TwoWay,
         UpdateSourceTrigger = UpdateSourceTrigger.Explicit
      };

      if (ElementName != null)
         binding.ElementName = ElementName;
      if (RelativeSource != null)
         binding.RelativeSource = RelativeSource;
      if (Source != null)
         binding.Source = Source;

      var expression = BindingOperations.SetBinding(targetObject, targetProperty, binding);

      PostBinding(targetObject, targetProperty, binding, expression);

      return targetObject.GetValue(targetProperty);
   }

   protected abstract void PostBinding(DependencyObject targetObject, 
      DependencyProperty targetProperty, Binding binding,
      BindingExpressionBase expression);
}

Now I’m not going to go over the code as you can read all about it in the MarkupExtension revisited post, but suffice to say we now inherit from this class and add our extension’s code to an implementation of the PostBinding method (I’m not mad on the method name but for now it’s the best I could think of).

So our DelayBindingExtension will now look like this

public class DelayBindingExtension : BindingBaseExtension
{
   private IDisposable disposable;

   public DelayBindingExtension()
   {			
   }

   public DelayBindingExtension(PropertyPath path) 
      : base(path)
   {
   }

   public int Delay { get; set; }

   protected override void PostBinding(DependencyObject targetObject, 
      DependencyProperty targetProperty, Binding binding,
      BindingExpressionBase expression)
   {
      var subject = new Subject<EventArgs>();

      var descriptor = DependencyPropertyDescriptor.FromProperty(
                          targetProperty, 
                          targetObject.GetType());
      descriptor.AddValueChanged(targetObject, (sender, args) => subject.OnNext(args));

      subject.Throttle(TimeSpan.FromMilliseconds(Delay)).
         ObserveOn(SynchronizationContext.Current).
         Subscribe(_ => expression.UpdateSource());
   }
}

Note: Please be aware that this implementation of the delay binding extension has a possible memory leak. Basically we’re rooting the object with the call to AddValueChanged and not calling RemoveValueChanged the remove this link.

MarkupExtension revisited

In a previous post I looked at using the MarkupExtension to remove the need for adding Converters as resources, see MarkupExtension. For this post I’m going to look at implement a MarkupExtension to in place of a Binding, i.e.

Disclaimer: All the code listed works, but I’ve not tested in all scenarios

<TextBox Text="{Binding SomeProperty}"/>

What are we going to implement ?

WPF in .NET 4.5 has the concept of Delay property on a Binding which is used as follows

<TextBox Text="{Binding SomeProperty, Delay=500}"/>

This is used on a Binding to only update the source (after a change on the target) after a user-specified delay. The most obvious use of such a mechanism is when the user types into a search or filter text box and you don’t want to be searching and filtering for every change. Preferably code will wait for the user to pause for a short time then carry out the search or filter functionality.

Now .NET 4.0 doesn’t have such a property on the Binding class, so we’re going to implement a very basic approximation of the Binding class in .NET 4.0 (mainly because the current project I’m working on targets .NET 4.0).

Why can’t be simply inherit from the Binding class ?

Unfortunately we cannot simply inherit from the Binding class to add our new code. The ProvideValue method of the MarkupExtension is marked as sealed and not override-able. But hey, where would the fun be if it was all that easy…

Let’s write some code

By convention, as with .NET Attributes, we suffix our extension class name with “Extension” but when it’s used, in XAML, the “Extension” part can be ignored. So first up let’s create the barest of bare bones for our DelayBindingExtension.

[MarkupExtensionReturnType(typeof(object))]
public class DelayBindingExtension : MarkupExtension
{
   public override object ProvideValue(IServiceProvider serviceProvider)
   {
      // To be implemented
      return null;
   }
}

Note: The MarkupExtensionReturnType simply gives WPF information on what to expect as the return type from the ProvideValue method.

Let’s take a quick look at how we expect to use this extension in XAML (which should look pretty similar to the .NET 4.5 implementation show earlier)

<TextBox Text="{markupExtensionTest:DelayBinding Path=MyProperty, Delay=500}"/>

Before we implement the ProvideValue method, let’s add the other binding properties which most people will expect to see

[MarkupExtensionReturnType(typeof(object))]
public class DelayBindingExtension : MarkupExtension
{
   public DelayBindingExtension()
   {			
   }

   public DelayBindingExtension(PropertyPath path) 
   {
      Path = path;
   }

   [ConstructorArgument("path")]
   public PropertyPath Path { get; set; }
   public IValueConverter Converter { get; set; }
   public object ConverterParameter { get; set; }
   public string ElementName { get; set; }
   public RelativeSource RelativeSource { get; set; }
   public object Source { get; set; }
   public bool ValidatesOnDataErrors { get; set; }
   public bool ValidatesOnExceptions { get; set; }
   [TypeConverter(typeof(CultureInfoIetfLanguageTagConverter))]
   public CultureInfo ConverterCulture { get; set; }

   public int Delay { get; set; }

   public override object ProvideValue(IServiceProvider serviceProvider)
   {
      // To be implemented
      return null;
   }
}	

Right, those properties will make our extension appear like a Binding object, obviously with our addition of the Delay property.

Now it’s time to implement the ProvideValue method. I’m going to use Reactive Extensions to handle the actual delay (throttling) of the property change events. I’ll list the code and then discuss it afterwards

public override object ProvideValue(IServiceProvider serviceProvider)
{
   var pvt = serviceProvider.GetService(typeof(IProvideValueTarget)) as IProvideValueTarget;
   if (pvt == null)
      return null;

   var targetObject = pvt.TargetObject as DependencyObject;
   if (targetObject == null)
      return null;

   var targetProperty = pvt.TargetProperty as DependencyProperty;
   if (targetProperty == null)
      return null;

   var binding = new Binding
   {
      Path = Path, 
      Converter = Converter,
      ConverterCulture = ConverterCulture,
      ConverterParameter = ConverterParameter,
      ValidatesOnDataErrors = ValidatesOnDataErrors,
      ValidatesOnExceptions = ValidatesOnExceptions,
      Mode = BindingMode.TwoWay,
      UpdateSourceTrigger = UpdateSourceTrigger.Explicit
   };

   if (ElementName != null)
      binding.ElementName = ElementName;
   if (RelativeSource != null)
      binding.RelativeSource = RelativeSource;
   if (Source != null)
      binding.Source = Source;
  
   var expression = BindingOperations.SetBinding(targetObject, targetProperty, binding);

   var subject = new Subject<EventArgs>();

   var descriptor = DependencyPropertyDescriptor.FromProperty(
                       targetProperty, targetObject.GetType());
   descriptor.AddValueChanged(targetObject, (sender, args) => subject.OnNext(args));

   subject.Throttle(TimeSpan.FromMilliseconds(Delay)).
      ObserveOn(SynchronizationContext.Current).
      Subscribe(_ => expression.UpdateSource());

   return targetObject.GetValue(targetProperty);
}

Note: The first line where we see if the IServiceProvider supports the IProvideValueTarget interface uses the GetService method. If you use the serviceProvider as IProvideValueTarget way of obtaining the interface you’ll find the MarkupExtension will not be able to cast from an InstanceBuilderServiceProvider to the IProvideValueTarget meaning the code will return null and not the actual bound property at design time. At runtine all will work.

So the first few lines of code are all about getting the interfaces and objects we want before proceeding to the interesting part of the method. This is the point where we create a binding object and supply all the information it expects.

Notice also that for ElementName, RelativeSource and Source we check whether the user actually supplied these values before overwriting the default values. This is important. If we set one of these properties to null we might appear to be supplying the properties with the same value they already have (and ordinarily we’d expect nothing to change) but in fact we’ll be causing the Binding to change from an unset state to set and with the value null. This will stop the property using it’s default behaviour.

So for example setting Source to null (even though it will say it’s null), will stop it using any parent DataContext and ofcourse not bind to anything.

Note: we can return a property to it’s default state using DependencyProperty.UnsetValue

After creating the Binding and applying the properties we call BindingOperations.SetBinding to associate the binding with the target object and target property.

Next we’re going to basically connect to the target property value change events on it’s dependency property. This allows us to handle a dependency property’s value changed event in a generic way, so for a TextBox Text property we’ll respond to the TextChanged event whilst if we use this code on a CheckBox we’ll handle the IsChecked change event and so on.

I’m using the Reactive Extensions in this example as it makes things so much simpler. We’re going to create a Subject and then from this we’ll be using Throttle so we can implement the delay, i.e. Throttle will not call the Action associated with the Subscribe method until a period of inactivity on the property change event – the inactivity timeout obviously being the Delay we set, in milliseconds.

When the Subscribe method’s Action method is called we simply tell the binding expression to Update the source and the data is written to the view model.

You’ll notice we return the property value for the target object at the end of the method. Obviously if the property has data when the binding is first created, this will now be displayed when the control is instantiated.

References

Starting out with R

This will be a simple “getting started” post on the R environment and language. R is a statistical language which is also heavily used in data mining and machine learning.

For this post I’m using R version 3.1.2 and the free version of R Studio 0.98.1087. Assuming we have R installed and then R Studio, let’s get started…

Demos

Let’s start by looking at the demo command. Typing demo() within the console of R Studio will list the available demos within the packages installed. So if we install further packages which contain demos, these will be available when you invoke the demo command.

So demo will list the demos within the packages, we can invoke

demo(package='graphics')

to get the graphics package demos and to run a demo simply type

demo(image)

for example to run the image demo.

To find a list of all demos within all packages we can invoke

demo(package = .packages(all.available=TRUE))

R scripts

By default we can execute commands in the R console, but ofcourse we might wish to put a whole bunch of commands together into a script file, so within R Studio we can use Ctrl+Shift+N to create a new script file and then obviously enter the script. We can then run the script using Ctrl+Shift+S (or Code | Source).

Help

The help function can be invoked from the console or R Studio to view help on a function/command, (this will load an HTML page, in the case of R Studio this is displayed within the IDE)

# display the help documentation
help() 

# display the help documentation for the vector type
help(vector)

We can also use the shortcut ? to invoke the help

?vector

Vignette

Vignettes are documents (in PDF format) which are available as help for packages.

vignette()

the above will, like demo() list all vignettes in the packages.

Again we can list all vignettes across all packages using

vignette(package = .packages(all.available = TRUE))

and you guessed it we can equally run the following to list the vignettes within a specific package

vignette(package = 'grid')

Finally to invoke a vignette we simple execute

vignette('grid')

to execute a specific vignette on a specific package we can equally write

vignette('moveline', package='grid')

Double or single quote symbols?

We can use either double or single quotes, interchangeably within R but obviously if we want to embed a single or double quote within a string, we can use the other type of quote, for example

s <- 'This is a "double quote" string'

As per C# we can equally use the backslash to escape the quote

s <- "This is a \"double quote\" string"

Comments

Before we start writing code, let’s look at how to write comments within R. The # is used to prefix a comment, for example

# this is a comment

Variables

Like most programming languages, we want ways to store data, like F# we use the <- operator to assign values to a variable, i.e. [code language="R"] x <- 123 [/code] so obviously in the above x is the variable name and is now assigned the value 123. We can also use the assign variables using the assign function, for example [code language="R"] assign("x", 123) [/code] notice the variable name is written as a string. We can also use -> and = to assign variables

123 -> x

x = 123

however the equals operator is rarely used from what I can tell, partly because it can have different meanings in different situations.

Variable names in R can be made up of letters, numbers, dot and underline characters. Variables must start with a letter or dot (note: a dot cannot be followed by a number as a variable name). Ofcourse like other languages, R keywords cannot be used for variable names.

If you’re interested in R style guidelines which include guidelines for variable naming styles, checkout Google’s R Style Guide.

Once we create a variable it’s added to the global environment, but we might also wish to remove a variable from the global environment, to do this execute

rm("x")

# or use

remove("x")

where x is the variable name we want to remove.

Finally we can view the values within a variable using

print(x)

# or simply typing the variable name and pressing enter

x

either of the above will output the value stored within the variable x.

Scope/Environments

If we simply assign variable (as previously discussed) the variable will be added to the environment/global scope, however we can also create alternate scope known as a custom environment.

We create a new environment using the followings

e <- new.env()

where e is a variable of type Environment. We can then assign variables to this environment using

assign("x", 123, e)

# or 

e[["x"]] <- 123

#or

e$x <- 123

in all of the above our new environment variable e is used and the variable x is created within the environment scope and assigned the value 123.

Note: in the last example with the $ quotes are optional around the variable name

To output the variable from the new Environment we can simply type

e$x

# or

get("x", e)

# or

e[["x"]]

More on Environments

We can also get a variable from the global environment using get, such as

get("x", globalenv()) 

and if we want to find the parent environment to a custom environment we can use

parent.env(e)

Operators

We’ve already covered the assignment operator <-, let's look at some of the other available operators. Arithmetic Operators

a <- 10  # assign a the value 10
b <- 5   # assign b the value 5

a + b    # addition operator
a - b    # subtraction operator
a * b    # multiplication operator
a / b    # division operator
a ^ b    # exponent operator
a ** b   # alternate exponent operator
a %% b   # modulus operator
a %/% b  # integer division

Logical operators

a < b    # less than operator
a > b    # greater than operator
a <= b   # less than or equal operator
a >= b   # less than or equal operator
a == b   # equality operator
a != b   # not equal operator
!a       # logical NOT operator
a | y    # logical OR operator
a & y    # logical AND operator

We can also use the function isTRUE(a) to test if a variable is TRUE.

This covers the real basics of getting up and running with R. I hope to create further posts covering more aspects of R real soon.

WPF behaviors

Behaviors came into WPF via Expression Blend. They’re basically a standardized way of adding extra functionality to WPF classes using XAML. So why not use attached properties you might ask. I’ll discuss the differences as we go.

Let’s look at a real world example…

I’m using Infragistics XamDataGrid to display rows of data, but I would like a simple filtering mechanism so that when the user enters text into a text box, all columns are filtered to show data with the filter text in it. I also want it so that when the text box is cleared the filters are cleared. Then I want a Button to enable me to clear the filter text for me with the click of the button.

How might we implement this ? Well the title of the post is a giveaway, but let’s look at some other possibilities first

  • We could write this in the code-behind but generally we try to stay clear of writing such code and instead would generally prefer use XAML to help make our code reusable across projects
  • We could derive a new class from the XamDataGrid and add dependency properties, but this means the code will only be usable via our new type, so it’s not as useful across other projects as it requires anyone wanting to use a XamDataGrid to use our version
  • We could use attached properties, which allow us to create “external” code, i.e. code not in code behind or in a derived class, which can work in conjunction with a XamDataGrid, but the problem here is that attached properties are written in static classes and we will want to store instance variables with the data (see my reasons for this requirement below). With a static class implementation we would have to handle the management of such data ourselves, not difficult, but not ideal.

The attached properties route looked promising – I’m going to need a property for the associated TextBox (acting as our filter text) and the Button (used to clear the filter) and ofcourse these may be different per instance of a XamDataGrid – I also need to handle the attachment and detachment of event handlers and any other possible state. As mentioned, we could implement such state management ourselves, but behaviors already give us this capability out of the box as they are created on a per instance basis.

So the best way for to think of a behavior is that it’s like attached properties but allows us to create multiple instances of the code and thus saves us a lot of the headaches that might occur managing multiple instance data.

Note: The code I’m about to show/discuss includes Reactive Extension code. I will not go into any depth on what it does or how it works but the main use here is to handle attachment and detachment of events and also to allow throttling of the input, this means as the user types in the filter text box, we do not update the filter until the user stops typing for half a second. This ensures we’re not continually updating the filters on the XamDataGrid as the user types

Creating a behavior

To create a behavior we simply create a class and derive it from the Behavior class which is part of the System.Windows.Interactivity namespace. The Behavior takes a generic argument which defines the type it can be used on. So to start off our code would look like this

public class XamDataGridFilterBehavior : Behavior<XamDataGrid>
{
   protected override void OnAttached()
   {
      base.OnAttached();
   }

   protected override void OnDetaching()
   {
      base.OnDetaching();
   }
}

So the key parts here (apart from the base class which has already been mentioned) are the OnAttached and OnDetaching overrides. So here we can attach and detach from events on the associated class (i.e. the XamDataGrid) and/or handle initialization/disposal of data/objects as required.

Before we look at a possible implementation of these methods, I wrote a simple list of requirements at the top of this post. One was the requirement for a TextBox to be associated with the XamDataGrid to act as the filter text and the other a Button to be associated to clear the filter. So let’s add the dependency properties to our class to implement these requirements.

public static readonly DependencyProperty FilterTextBoxProperty =
   DependencyProperty.Register(
   "FilterTextBox",
   typeof(TextBox),
   typeof(XamDataGridFilterBehavior));

public TextBox FilterTextBox
{
   get { return (TextBox)GetValue(FilterTextBoxProperty); }
   set { SetValue(FilterTextBoxProperty, value); }
}

public static readonly DependencyProperty ResetButtonProperty =
   DependencyProperty.Register(
   "ResetButton",
   typeof(Button),
   typeof(XamDataGridFilterBehavior));

public Button ResetButton
{
   get { return (Button)GetValue(ResetButtonProperty); }
   set { SetValue(ResetButtonProperty, value); }
}

So nothing exciting there, just standard stuff.

Now to the more interesting stuff, let’s implement the OnAttached and OnDetaching code. As I’m using Reactive Extensions we’ll need to have two instance variables, both of type IDisposable to allow us to clean up/detach any event handling. Let’s see all the code

private IDisposable disposableFilter;
private IDisposable disposableReset;

protected override void OnAttached()
{
   base.OnAttached();

   var filter = FilterTextBox;
   if (filter != null)
   {
      disposableFilter = Observable.FromEventPattern<TextChangedEventHandler, TextChangedEventArgs>(
         x => filter.TextChanged += x,
         x => filter.TextChanged -= x).
         Throttle(TimeSpan.FromMilliseconds(500)).
         ObserveOn(SynchronizationContext.Current).
         Subscribe(_ =>
         {
            var dp = AssociatedObject as DataPresenterBase;

            if (dp != null && dp.DefaultFieldLayout != null)
            {
               dp.DefaultFieldLayout.RecordFilters.Clear();
               dp.DefaultFieldLayout.Settings.RecordFiltersLogicalOperator = LogicalOperator.Or;

               foreach (var field in dp.DefaultFieldLayout.Fields)
               {
                  var recordFilter = new RecordFilter(field);
                  recordFilter.Conditions.Add(
                     new ComparisonCondition(ComparisonOperator.Contains, filter.Text));
								                  
                  dp.DefaultFieldLayout.RecordFilters.Add(recordFilter);
               }
           }
      });
   }

   var reset = ResetButton;
   if (reset != null)
   {
      disposableReset = Observable.FromEventPattern<RoutedEventHandler, RoutedEventArgs>(
         x => reset.Click += x,
         x => reset.Click -= x).
         ObserveOn(SynchronizationContext.Current).
         Subscribe(_ =>
         {
             FilterTextBox.Text = String.Empty;
             // whilst the above will clear the filter it's throttled so can
             // look delayed - better we clear the filter immediately
             var dp = AssociatedObject as DataPresenterBase;

             if (dp != null && dp.DefaultFieldLayout != null)
             {
                dp.DefaultFieldLayout.RecordFilters.Clear();
             }
        });
    }
}

protected override void OnDetaching()
{
   base.OnDetaching();

   if (disposableFilter != null)
   {
      disposableFilter.Dispose();
      disposableFilter = null;
   }
   if (disposableReset != null)
   {
      disposableReset.Dispose();
      disposableReset = null;
   }
}

This post isn’t mean’t to be about using the RX library or Infragistics, but the basics are that when OnAttached is called we use the RX FromEventPattern method to create our event handler attachment/detachment points. In the case of the TextBox we attach to the KeyDown event on the TextBox, we throttle the Observable for half a second so (as previously mentioned) we don’t update the filters on every change of the TextBox, we delay for half a second to allow the user to pause and then we filter. We also ensure the Subscribe code is run on the UI thread (well as the code that call OnAttached will be on the UI thread we’re simply observing on the current thread, which should be the UI thread). In the Subscribe method we get the AssociatedObject, this is where our Behavior generic argument comes in. The AssociatedObject is the object this behavior is applied to (we’ll see a sample of the XAML code next). Now we clear any current filters and create new ones based upon the supplied TextBox Text property. Finally we connect to the Click event on the supplied ResetButton. When the button is pressed we clear the FilterText and clear the filters.

In the code above I felt that the UX of a delay between clearing the FilterText and the filters clearing (the half a second delay) didn’t feel right when the user presses a button, so in this instance we also clear the filters immediately.

The OnDetaching allows us cleanup, so we dispose of our Observables and that will detach our event handlers and nicely clean up after usage.

How do we use this code in XAML

Finally, we need to see how we use this code in our XAML, so here it is

<TextBox x:Name="filter"/>
<Button Content="Reset" x:Name="reset" />

<XamDataGrid>
   <i:Interaction.Behaviors>
     <controls:XamDataGridFilterBehavior 
        FilterTextBox="{Binding ElementName=filter}" 
        ResetButton="{Binding ElementName=reset}" />
   </i:Interaction.Behaviors>
</XamDataGrid>

And that’s it, now we have a reusable class which a designer could use to add “behavior” to our XamDataGrid.