Wednesday 30 June 2010

Binding Modes in Silverlight

There are 3 binding modes in Silverlight (identified by the BindingMode enumeration):

  • OneTime - bindings update the target with the source data when the binding is created
  • OneWay - bindings update the target with the source data when the binding is created and anytime the data changes. This is the default mode.
  • TwoWay - bindings update both the target and the source when either changes. Alternately, you can disable automatic source updates and update the source only at times of your choosing. When the binding is created, the target property is updated from the source.

In OneWay or TwoWay bindings, the source object must implement INotifyPropertyChanged in order for the target to update when the source changes.

For TwoWay bindings, changes to the target do not automatically propagate to the source, except if the binding target is the Text property. In that case, the update happens only when the TextBox loses focus. In other words, the in-memory object to which the TextBox is bound isn’t modified until the TextBox loses focus whereas other elements perform their updates immediately (e.g. the user moves a bound slider control). If you need a TextBox to update as the user types you must implement an event handler on the TextBox TextChangedEvent. For example:

private void myTextBox_TextChanged(object sender, TextChangedEventArgs e)
    BindingExpression exp = myTextBox.GetBindingExpression(TextBox.TextProperty);

For OneTime and OneWay bindings, calls to SetValue automatically change the target value and delete the binding.


Monday 28 June 2010

Using Commands in Silverlight

Commands in Silverlight are a valuable way of getting away from the code-behind, event handler trap and keeping the UI decoupled from application logic. When used in combination with the MVVM pattern, what would have been event handlers are now effectively properties on the ViewModel (properties that return an object that implements ICommand), bound to the Command property of UI elements such as buttons.
Note: The command approach works well for instances where a UI element is clicked (e.g. buttons) so the resulting code (the command) is executed once. In cases where values are constantly changing (e.g. the value of a slider control) the command approach falls down; you can’t attach a command to a UI element event handler. For such event-driven scenarios you need to use a different approaches: use behaviours, bind the changing value to a property in the ViewModel that in turn updates other bound properties when changed, or create user controls and create dependency properties for the changing values which are bound via the ViewModel.
Before going further be aware that Prism (the Composite Application Library) already has some support for commanding. The Composite Application Library provides the DelegateCommand and CompositeCommand classes to simplify command implementation.
See the Commands technical overview:
A DelegateCommand implementation might look something like this:
public class DelegateCommand : ICommand { private Func<object, bool> _canExecuteFunc;
    private Action<object> _executeAction;
    private bool _canExecute;
    public event EventHandler CanExecuteChanged;

    public DelegateCommand(Action<object> executeAction, Func<object, bool> canExecuteFunc)
        _executeAction = executeAction;
        _canExecuteFunc = canExecuteFunc;

    public bool CanExecute(object parameter)
        bool temp = _canExecuteFunc(parameter);
        if (_canExecute != temp)
            _canExecute = temp;
            if (CanExecuteChanged != null)
                CanExecuteChanged(this, new EventArgs());
        return _canExecute;
    public void Execute(object parameter)
To use a DelegateCommand you then need to define a command property on the view model:
public ICommand MyCommand { get; set; }
and then instantiate a DelegateCommand passing in the appropriate methods for CanExecute and Execute:
LoadProductsCommand = new DelegateCommand(MyMethod, CanExecuteMyMethod);
The DelegateCommand can be bound to a UI control:
<Button Content="Push Me" Command="{Binding MyCommand}" />
It is possible to pass parameters to the command:
<Button Content="Push Me" Command="{Binding MyCommand}" CommandParameter="{Binding ElementName=SomeUiEelement, Path=Text}" />
Monday 28 June 2010

Friday 25 June 2010

WCF RIA Services basics

This post is mainly concerned with the basics of WCF RIA Services and is intended to serve as a aide memoire for terms etc. It will be added to over time.
Some definitions:
  • Project Link
    • The server project references the domain services, shared code etc. defined on the server side.
    • Code is generated in the client project at compile time linking the client and the server.
  • Entities
    • Defined on the server and generated client-side.
    • Validation etc. also generated on the client side (i.e. you just maintain the single server-side definition).
    • Used to marshal the data across the WCF service.
    • Can be created with Entity Framework, LINQ to SQL, or POCOs.
  • Domain Service
    • Defines the operations supported on the server side (e.g. CRUD operations).
    • Can be arbitrary operations to be invoked on the server from the client exposed by WCF.
  • Domain Context
    • The client side counterpart to the Domain Service.
    • Generated code on the client side.
    • Contains a WCF proxy that makes the service calls.
    • Manages creating the queries to be executed on the server side, entity change tracking etc.
  • Domain Data Source
    • Used to execute queries and submit changes to the server side.
    • Associated with the domain context.
    • Makes calls through the domain context to query and update entities.
    • Facilitates direct data binding from XAML.
Entities or entity collections retrieved are cached through the domain context on the client side. Changes (i.e. the addition, deletion or update of entities) are effectively ‘stored’ in the Domain Context until the changes are flushed through to the database. In other words, the Domain Context must be kept around long enough to submit the changes.
The Domain Context Load and SubmitChanges execute asynchronously. They take a thread from the thread pool, make the necessary calls to the server, and when those calls complete the work is automatically marshalled back to the UI thread to modify the entity collections and subsequently update the UI (probably via INotificationChanged).
However, it would be prudent to assume at least the possibility of problems. A couple of strategies that can be employed to get around this are:
  • Subscribe to the Completed event obtained from the LoadOperation or SubmitOperation obtained from Load or SubmitChanges.
  • Call an overload of the Load or SubmitChanges that takes an Action<LoadOperation> or Action<SubmitOperation> (i.e. supply call-backs).


When creating the Domain Service (server side) adding the EnableClientAccess attribute will cause client side code to be generated at compile time.
Operations in the Domain Service can be decorated with attributes to identify their purpose (e.g.  create, read, update or delete and entity instance).
Authentication and authorisation can be enforced using attributes (the attributes can be specified at the service or operation level):
  • RequiresAuthentication - prevents anonymous users from accessing a service to perform an operation.
  • RequiresRole - ensures that the current principal belongs to one of the specified roles.

Convention over configuration

By default WCF RIA Services uses convention over configuration to find appropriate operations defined in the Domain Service.  There are a set of named method prefixes WCF RIA Services is looking for (e.g. Update***, Insert***, Delete***).
As an alternative attributes can be used to decorate methods and indicate what they are to be used for (i.e. configuration).

Authentication and authorisation

On the client authentication functionality is accessed through a class called WebContext, a class that represents functionality provided by the web server.
Authentication services implement the IAuthentication interface. An implementation of an authentication service will use a DomainContext to work against the corresponding DomainService implementing IAuthentication on the server.
There are 2 approaches to implementing authentiaction:
1. Derive from the out-of-box AuthenticationService base class. This provides a default implementation that leverages the membership, roles and profile infrastructure.
2. Implement IAuthentication on your domain service and do whatever you like based on your unique scenarios when implementing Login, Logout and other methods of the interface. This is especially useful if you're not using the infrastructure services or want to use some custom auth mechanism.
See and
Authorisation can be further controlled using attributes (see above).

Monday 21 June 2010

Design resources for application development

I thought it was time to keep track of some interesting resources relevant to interface design.


UX and UI Patterns

Windows Phone 7


  • The Elements of Graphic Design (ISBN 1581152507)
  • How to Think Like a Great Graphic Designer (ISBN 1581154968)
  • The Elements of Typographic Style (ISBN 0881792063)
  • The Internet: A Writer’s Guide (ISBN 071365192X)


  • Typography Now Two (ISBN 186154023X)
  • Website Graphics Now (ISBN 050028119X) – old but still fun.
Monday 21 June 2010

Physics engines for Silverlight

I’ve been looking around at physics engines for Silverlight and a couple have surfaced as being potentially usable.


Although originally a C++ project ( there are C# ports available. One example can be found in the behaviours library available here: This code includes a Box2D.SL project.

What is interesting about this Box2D implementation is that it has been demonstrated to work on the Windows Phone 7.


The Farseer Physics Engine is an easy to use 2D physics engine designed for Microsoft’s XNA and Silverlight platforms. The Farseer Physics Engine focuses on simplicity, useful features, and enabling the creation of fun, dynamic games.

I think Farseer has been used by the developer of Silversprite, the platform for allowing XNA games to run in Silverlight.

Physics Helper for Silverlight, WPF, Blend, and Farseer

The Physics Helper for Blend, Silverlight and WPF contains several Behaviors and controls which allow you to draw objects in Expression Blend 3, and have those objects translated directly into Physics objects using the Farseer Physics Engine. This can be a great timesaver for creating games, as it is traditionally difficult to line up underlying physics bodies and geometries with your Blend artwork.

Monday 14 June 2010

Gradient brushes in Silverlight

Before going any further look at this for an explanation of brushes, including gradients:

It’s useful to visualise what’s going on with gradient brushes so here is an example application with 3 pages each showing a rectangle with either a linear gradient fill or a radial gradient fill. There are 2 examples of linear gradients and one of a radial gradient. Of the linear gradient examples one has 2 gradient stops and the other 3.

Move the sliders to see the effect of different parameters on a gradient.

Get Microsoft Silverlight

The following XAML snippets show rectangles from the 3 examples so you can see how the binding is working.

Radial gradient

<Rectangle x:Name="rectFilled" Width="200" Height="100" Margin="0,5" HorizontalAlignment="Left">
    <RadialGradientBrush GradientOrigin="{Binding GradientOrigin}" Center="{Binding Center}" RadiusX="{Binding RadiusX}" RadiusY="{Binding RadiusY}">
      <GradientStop x:Name="yellowGradientStop" Color="Yellow" Offset="{Binding YellowOffset}" />
      <GradientStop x:Name="redGradientStop" Color="Red" Offset="{Binding RedOffset}" />

Linear gradient with 2 gradient stops

<Rectangle x:Name="rectFilled" Width="200" Height="100" Margin="0,5" HorizontalAlignment="Left">
    <LinearGradientBrush x:Name="lgbGradient" StartPoint="{Binding StartPoint}" EndPoint="{Binding EndPoint}">
      <GradientStop x:Name="yellowGradientStop" Color="Yellow" Offset="{Binding YellowOffset}" />
      <GradientStop x:Name="redGradientStop" Color="Red" Offset="{Binding RedOffset}" />

Linear gradient with 3 gradient stops

<Rectangle x:Name="rectFilled" Width="200" Height="100" Margin="0,5" HorizontalAlignment="Left">
    <LinearGradientBrush x:Name="lgbGradient" StartPoint="{Binding StartPoint}" EndPoint="{Binding EndPoint}">
      <GradientStop x:Name="yellowGradientStop" Color="Yellow" Offset="{Binding YellowOffset}" />
      <GradientStop x:Name="blueGradientStop" Color="Blue" Offset="{Binding BlueOffset}" />
      <GradientStop x:Name="redGradientStop" Color="Red" Offset="{Binding RedOffset}" />

Friday 11 June 2010

Sizing elements in Silverlight

I keep having to remind myself about sizing in Silverlight but it’s easy really:

Sizing Type Description Usage
Absolute Choose the exact size in pixels. Changing the container size has no effect. Width=”100”
Automatic Element is given the exact amount of space it needs and no more. Width=”Auto”
Proportional Space is divided between elements in a group (e.g. rows in a Grid). A number can be given to proportionally assign space. Width=”*”

For example:

<Grid x:Name="LayoutRoot">
        <RowDefinition Height="0.25*" />
        <RowDefinition Height="1.5*" />
        <RowDefinition Height="1*" />
Friday 11 June 2010

Tuesday 8 June 2010

2D Matrix transforms in Silverlight

“A 3x3 matrix is used for transformations in a two-dimensional x-y plane. Affine transformation matrices can be multiplied to form any number of linear transformations, such as rotation and skew (shear), followed by translation. An affine transformation matrix has its final column equal to (0, 0, 1), so only the members in the first two columns need to be specified. Note that vectors are expressed as row-vectors, not column vectors.” *

Affine transformations preserve collinearity and relative distancing in a transformed coordinate space:

  • Points on a line will remain in a line after an affine transformation
  • Parallel lines remain parallel
  • Relative spacing or distancing will always maintain at a consistent ratio.

Affine transformations allow for repositioning, scaling, skewing and rotation. Things they cannot do include tapering or distorting with perspective.

The transformation matrix looks like this (default values in brackets):

M11 (1.0) M12 (0.0) 0
M21 (0.0) M22 (1.0) 0
OffX (0.0) OffY (0.0) 1

The elements ion the matrix map as follows:

  • M11 = X Scale
  • M12 = Y Skew
  • M21 = X Skew
  • M22 = Y Scale
  • OffX = translation on X axis
  • OffY = translation on Y axis


X Scale Y Skew 0
X Skew Y Scale 0
X translation Y translation 1

Note you cannot change the values of the 3rd column in the Matrix class (i.e. 0, 0, 1).

For example, to create a matrix that scales but changes no other parameters:

double scaleX = 0.5;
double scaleY = 0.5;
Matrix mx = new Matrix(scaleX, 0.0, 0.0, scaleY, 0.0, 0.0);

A quick bit of revision; the following is an identity matrix:

1 0 0
0 1 0
0 0 1

This applies no transformation whatsoever:

x' = x*1 + y*0 + 0
y' = x*0 + y*1 + 0

which reduces to

x' = x
y' = y

Note that the the matrix for the point will be [x, y, 1].

* Matrix Structure -

See also:

Attached vs regular dependency properties

With dependency properties the backing store of the property is an object of type DependencyProperty instead of what would normally be a private field. Dependency properties can come in 2 forms: attached or not attached.

Regular dependency properties are set on a DependencyObject just like any other .NET property.

Attached dependency properties are associated with a DependencyObject (e.g. Grid) but are set on a separate DependencyObject, often a child of the DependencyObject that defines the attached property (e.g. Grid.Row, an attached property, is set on the children of a parent Grid).

An attached property is a concept defined by Extensible Application Markup Language (XAML). An attached property is intended to be used as a type of global property that is settable on any object…

…One purpose of an attached property is to allow different child elements to specify unique values for a property that is actually defined in a parent element. A specific application of this scenario is having child elements inform the parent element of how they are to be presented in the user interface (UI). *

When manipulating dependency properties in code the DependencyProperty.Register() method is used to register a normal unattached dependency property on a DependencyObject. DependencyProperty.RegisterAttached() is used to set an attached dependency property.

If your class is defining the attached property strictly for use on other types, then the class does not have to derive from DependencyObject. But you do need to derive from DependencyObject if you follow the overall WPF model of having your attached property also be a dependency property.

Define your attached property as a dependency property by declaring a public static readonly field of type DependencyProperty. You define this field by using the return value of the RegisterAttached method. The field name must match the attached property name, appended with the string Property, to follow the established WPF pattern of naming the identifying fields versus the properties that they represent. The attached property provider must also provide static GetPropertyName and SetPropertyName methods as accessors for the attached property; failing to do this will result in the property system being unable to use your attached property. * (my bold)


See also

Dependency property example

public string MyProperty 
    get { return (string)GetValue(MyPropertyProperty); }
    set { SetValue(MyPropertyProperty, value); } 

public static readonly DependencyProperty MyPropertyProperty = DependencyProperty.Register("MyProperty", typeof(string), typeof(MyClass), new PropertyMetadata(""));

The Register() static method accepts a class of type PropertyMetadata that, among other things, sets the default value of the property. Remember there is also a RegisterAttached() version for attached properties.

Differences between Silverlight and WPF

The differences between Silverlight and WPF reside in the metadata structure: Silverlight only supports the PropertyMetadata class here, while WPF supports several classes (all derived from PropertyMetadata).

Sunday 6 June 2010