Archive for September, 2010


Talking XNA with Shawn Hargreaves and Charles Cox

by David Wynne

To a lot of .Net developers XNA often appears to be a bit of an enigma – they might know roughly what it is, but they’re not really sure of its placement in the market or relevance to their work.  With Windows Phone 7 XNA is being edged into the limelight a little more and developers will no doubt be wondering whether it’s for them.

One of the great things about the work we’re doing with XPF, is in lowering that bar to entry.  XPF’s out-of-the-box controls will be familiar to you if you’ve come from a WPF/Silverlight background, but they still embrace the mechanics of XNA; leading you slowly into the wonderful world of 3D programming.

In a recent Channel 9 video Shawn Hargreaves and Charles Cox, from the XNA team, give a great interview on what XNA is, how it’s used, and the platforms it’s available on.  If you’re at all interested in XNA, but aren’t sure where to start – this is a great intro.

One of the subjects that comes up is the oft-asked “XNA and XAML” question and you might notice that at around the 32min mark Shawn happens to mention something that sounds a lot like XPF. ;)

So if you’re interested in dipping your toe in the XNA water, why not start by checking out our XPF Getting Started guide, download the sample code and let us know how you get on.


Pocket Mechanic Prototype Demo

by Cain Ullah

Last week I wrote a blog XPF Demo: What’s in store describing some of XPF’s potential power to deliver 2D layouts in an XNA app, alongside 3D elements. In that post I also promised to post a video of us playing with the 3D model interface deployed onto a WP7 device.

So, as promised, you can view a video below with David taking you through some steps of manipulating a 3D prototype of a VW Beetle’s Distributor:

As described in the XPF Demo: What’s in store blog post, we will be building out a demo around this prototype to include XPF’s 2D layout functionality to illustrate the power of being able to combine 2D and 3D in such an elegant manner.

We’ll keep you posted with our progress as more nightly builds are delivered and will be following up with new videos and blog posts as we deliver more functionality.


XPF: Introducing Adapters (and Clipping)

by David Wynne

Chocolate Tools by Janne Moren One of the things we’ve always been very careful to do with XPF is to make sure that it doesn’t really know anything about XNA.  Everything is interface driven and the link to XNA is only made at the “last minute” in the implementation of those interfaces.

This gives us the advantage of easing our BDD specs (everything can be mocked) but it also opens up another intriguing possibility – XPF doesn’t necessarily have to be used for XNA.

To reinforce this separation we’ve introduced the concept of adapters.  Those currently using XPF will know that we already have adapters, in the pattern sense of the word, for SpriteBatch, SpriteFont and Texture2D – but we’re extending the adapter concept to encompass everything required to use XPF on a platform, such as XNA.

There isn’t actually much new in the codebase as a result but we have moved some code about and created a new assembly.  Alongside RedBadger.Xpf.dll you’ll now find RedBadger.Xpf.Adapters.Xna.dll.  RedBadger.Xpf no longer references any XNA assemblies, but obviously the adapter dll does.  (This structure is mirrored in the WP7 assemblies).

As it stands there is only one XPF adapter – XNA, but in time there maybe more whether they’re written by us or by you!  We’ll be publishing the source code for the XNA adapter in the near future and giving  you a few more details on how you go about writing your own adapters, but in the mean time you’ll probably want to get the latest build, add a reference to the XNA adapter and fix up your code (should be fairly straight forward).

Other Changes (including Clipping)

Build 24 also brings with it clipping, which has meant a few changes to the way in which the SpriteBatchAdapter works.  We needed finer grain control over the SpriteBatch Begin and End calls (we use Scissor Testing to perform clipping which requires a change in RasterizerState) so you’re no longer responsible for calling SpriteBatch.Begin/End either-side of your call to RootElement.Draw.  To enforce this SpriteBatchAdapter no longer adapts SpriteBatch to ISpriteBatch via inheritance, but rather containment – so you physically can’t call Begin/End yourself.  This is consistent with the other adapters, so actually provides some nice usage symmetry too.

As a lot of the graphics related code has now been moved out of the main XPF assembly, we’ve re-organised our namespaces a bit.  Everything that was under Presentation has now moved up into the main Xpf namespace (Presentation is no longer).  We’ve also renamed XnaImage and ITexture2D to TextureImage and ITexture respectively.

As always, let us know how you’re getting on with XPF and thanks to all those who’ve provided feedback thus far, it’s been invaluable!


XPF Demo: What’s in store

by Cain Ullah

We are now getting to the point where we have enough functionality in the XPF public beta to start building out a demo application to showcase its functionality. We are going to use the requirements of the demo application to drive functionality that has not yet been built (bear in mind that we still want your feedback as it will also have an impact on our priorities of delivery).

Whilst my two business partners, Stu and David (the techy ones) have been enjoying themselves developing XPF and blogging in anger as new nightly builds are released with cool new functionality – I’ve been concentrating on all the non-techy stuff.

So, to give you a heads up of what is in store for the demo that we want to deliver over the coming weeks, this post will go through a few scamps I have done to show some designs of the demo’s functionality.

XPF exists to allow you to build powerful 2D layouts alongside the already powerful 3D functionality that XNA offers.  To showcase XPF functionality the demo will be an XNA application on WP7 with a whole bunch of fluid and logical 2D layouts, combined with some 3D elements too. We have built the story around a pocket mechanic application on which you can view lots of the usual 2D stuff such as – large amounts of textual information, navigate pivot pages (specific to WP7), view thumbnail galleries, view full-screen images (and navigate between them), view menus and app bars etc… you will also be able to interact with 3D models.

So, let’s have a look at some scamps around the pocket mechanic app:


Pivots         Pivots Nav

If you are familiar with WP7 you’ll already know that you can use long horizontal panoramic canvas’ that extend beyond the confines of the screen. It is as if you are using the phone as a magnifying glass to view content across the horizontal display (see to the right).

The horizontal canvas is made up of several pages, in this case pivot pages. A pivot is a control that allows you to navigate across large datasets or multiple pages. Flicking or panning horizontally on the page cycles the pivot, as does tapping a pivot header. In this case we have three pages: Text, Photos and 3D Parts.

The pivot control ships with the WP7 phone in Silverlight but remember this is an XNA app. To do this in XNA is somewhat of a challenge. So we will be using XPF to layout all of these pages, re-build the pivot control and create the animation and gestures to give a smooth experience when navigating between the pivot pages.

Textual Information

Textual Info The Text pivot page in the demo app will display a chapter of dummy text. This however could support full books of navigable text if necessary, using a Virtualizing Stack Panel.

An up or down swipe gesture will navigate through the text with the headings (chapter and section) remaining in place until you reach the next chapter or section. Such functionality is easy to implement with XPF’s Scroll Viewer.

Once animation is available in XPF, navigation will be in a smooth animated manner with built in physics controlling the speed of the text movement depending on the speed of the gesture.

To be able to build a 2D layout of navigable text, quickly, within an XNA app will be very powerful on both Windows and Windows Phone 7.

Thumbnail Galleries & Image Viewer


You can view a thumbnail gallery of images separated out into their respective chapters and sections with each of the thumbnails having a title and description. Data driven layouts like this are easy to implement in XPF using the ItemsControl which can be configured with any panel – a Wrap Panel might be a good choice here. It is possible to navigate through all of the images in the application via vertical flicks on this pivot page.

Tapping  a thumbnail takes you to full screen mode of that particular image. Once in full screen mode you are able to zoom and move the view of a single image using pinch and pan gestures. To navigate to the next picture without exiting full screen mode you flick horizontally and if you want to exit full screen mode you can either tap the back button on the phone’s hardware (to go back to the thumbnail view) or tap the home button on the app bar to return to start page of the application.

App Bar and Menu Items

With Silverlight applications on the WP7 you get an application bar which allows you to display up to four buttons used to invoke the most common application tasks. This does not ship with XNA applications. So, by using XPF we have created the ability to generate your own app bars to interact with your XNA application. In the demo we have a common app bar that will be consistent across the application as well as a menu item app bar that we will use to interact with the 3D content.

Lets have a quick look at the menu item app bar that we’ll use to interact with the 3D models…

When we are in 3D mode we want to provide a flexible way to manipulate the view of the model you are looking at. This will include picking a specific component within a model by interacting directly with the 3D model.

However, we also want to provide some contextual 2D textual information to show what you are looking at as well as some efficient ways to navigate to specific components on the model without having to interact with the 3D model itself. To do this, we are going to build a menu item.

Menu Item App Bar

As you can see in the scamp (above), when first entering into 3D mode for a specific model, you will be presented with the menu item that sits on top of the app bar. By default no component will be selected. Selecting the text (in this case ‘None Selected’) will present you with a list of selectable components or by using the left and right arrows you can cycle through the components one at a time. If you tap the text ‘None Selected’, the menu item will raise upward, revealing a list of components that you can select within the model. You can select any of the components from within the list and the menu item will collapse back down to the app bar (hiding the list) and you will be ‘flown’ to the optimum viewing angle of the specific component of the 3D model. Cycling through the components by using the left and right arrows “Flies to” and “Picks” components in the same way.

3D Content

Whilst the 3D content does not demonstrate XPF functionality directly, it does demonstrate the sort of situation that has brought about its creation – you would not be able to build this sort of 3D interactive functionality in Silverlight.  XPF allows you to combine both 3D and 2D, linking the two worlds using powerful data binding to create elegant implementations.


So to summarise, hopefully this blog will give you an idea of some of the things that you are able to build by using XPF within your XNA applications. Our complete set of scamps around this demo app are much more in-depth with lots more ideas for future functionality. However, what we actually build for a demo app will be closer to what I have talked about in this post.

We’ll post a video shortly of us playing with the 3D model interface deployed on a WP7 device.

We’ll continue to build out XPF with new cool features in the mean time. More blogs to follow and of course, more nightly builds.


XPF: Star Grid Length and Windows Phone 7 Orientation

by David Wynne

We recently added support to XPF’s Grid for star grid length.  Star grid lengths describe a grid layout using proportional values, allowing you to split up available space using percentages.  This can be extremely powerful, especially in situations when your host window changes size – think going in and out of full screen on Windows or changes in orientation on Windows Phone 7.

In our original Getting Started post, we had to use explicit row height and column widths creating a slightly inflexible structure.  Let’s rewrite the code using star grid lengths, but this time on Windows Phone 7.

Star Grid Length

We want to create a Grid with the following characteristics:


Because star is now the default grid length unit, to get the above layout we only have to provide explicit values on our top and bottom rows; making them a fixed height of 50 pixels each.  The middle row can default to what is effetely a value of 1 star, which will use 100% of the remaining space.  The 2 columns both have 1 star too and so will share the available horizontal space equally between them; 50% each.

var grid = new Grid
    Background = new SolidColorBrush(Colors.White), 
    RowDefinitions =
            new RowDefinition { Height = new GridLength(50) }, 
            new RowDefinition(), 
            new RowDefinition { Height = new GridLength(50) }
    ColumnDefinitions =
            new ColumnDefinition(),
            new ColumnDefinition()

The rest of the code from the Getting Started sample is exactly the same.  The result is a layout that stretches itself to the available space:


Windows Phone 7 Orientation

Now that we have a flexible layout, we can change the RootElement’s viewport whenever we want and XPF will re-evaluate our layout for us.  Let’s continue our example, by looking at how we might handle changes in orientation on WP7.  First let’s tell XNA that we can support all forms of orientation:

new GraphicsDeviceManager(this)
    SupportedOrientations =
        DisplayOrientation.Portrait |
        DisplayOrientation.LandscapeLeft |

Next we need to hook-up to the OrientationChanged event, changing XPF’s RootElement.Viewport in the handler.  You could do this using standard event handlers, but I’m going to use Reactive Extensions (Rx) so it will handle unhooking the event later if RootElement is disposed:

        handler => this.Game.Window.OrientationChanged += handler,
        handler => this.Game.Window.OrientationChanged -= handler)
    .Subscribe(_ => this.rootElement.Viewport = this.Game.GraphicsDevice.Viewport.ToRect());

That’s it we’re done.  Let’s fire it up and rotate our phone through 270 degrees and see the result:

A few lines of code and our entire layout becomes fluid and reflows without any manual intervention.  Building fluid layouts allows us to use the exact same code to target multiple resolutions and frees us from having to think too hard about how that impacts our implementation.

Star grid length and resizable RootElement are both available in the latest Nightly Build.


Inside XPF: Data Binding

by Stuart Harris

Updated 2010-09-20: Reflects the removal of the generic type parameter TOwner from ReactiveProperty (starting Build 20).

Neuroanatomical Connectivity Macaque by Arenamontanus In the previous post in this series, we discussed XPF’s Reactive Properties – the counterpart to Silverlight’s Dependency Properties.  Reactive Properties allow you to data bind to any source that implements the new .Net 4.0 IObservable<T> (for one-way binding) and/or any source that implements IObserver<T> (for one-way-to-source binding).  Two-way binding is simply a combination of the two.

The Reactive Object

In Silverlight, all UI Elements are derived from DependencyObject which the MSDN documentation says “Represents an object that participates in the dependency property system”.  In XPF all UI Elements are derived from ReactiveObject which represents an object that participates in the reactive property system.  ReactiveObject not only stores the current values of all the element’s reactive properties, but also allows you to bind to them in either (or both) directions.

The Bind method has overloads that allow you to bind a ReactiveProperty one-way to an IObservable, one-way-to-source to an IObserver or two-way to both.

The Binding Factory

So what do you do if the object you want to bind to doesn’t expose an IObservable/IObserver?  This is where the BindingFactory comes in.  The BindingFactory will create IObservables and IObservers around properties on either the data context or a specified source.

Binding to reactive properties, or properties on POCOs and objects that implement INotifyPropertyChanged is fully supported.  This enables element-to-element binding in addition to the use of familiar binding patterns often used in WPF/Silverlight such as Model View ViewModel (MVVM).

The observable/observer that the BindingFactory creates for you is internally wrapped in a Binding object which allows for either immediate or deferred resolution of the binding.  Immediate resolution is used when a reference to the source is provided, but if you are binding to an element’s data context then the binding resolution is deferred until the start of the Measure layout phase.  Deferred bindings are great because they allow the data context to be set or changed after the element binding has been declared.  This is essential for controls that use templates such as the ItemsControl.  The Binding’s resolution is handled seamlessly.

All data binding scenarios are supported.  The following table shows the various combinations of source objects/properties in each mode.  Note that binding to POCO properties works in both directions, but without INotifyPropertyChanged (INPC), one-way binding effectively becomes “one-time”.

Data Context
/Source Object
One-way Supported Supported Supported Supported
One-way-to-source Not applicable Supported Supported Supported
Two-way Not applicable Supported Supported Supported
(one-time and one-way-to-source)

Show me some code

Here are the overloads to ReactiveObject’s Bind method:


You’ll notice that because it’s a generic method, the parameters are strongly typed to match the target ReactiveProperty specified.  The scenario in the screenshot above shows binding to a source reactive property on the element’s data context.  The specification for this scenario looks like this:

[Subject(typeof(ReactiveObject), "One Way")]
public class when_there_is_a_one_way_binding_to_a_property_on_the_data_context
    private const double ExpectedWidth = 10d;

    private static SourceObject source;

    private static ContentControl target;

    private Establish context = () =>
            target = new ContentControl();

            IObservable<double> fromSource =
                BindingFactory.CreateOneWay<SourceObject, double>(SourceObject.WidthProperty);
            target.Bind(UIElement.WidthProperty, fromSource);

            source = new SourceObject();
            target.DataContext = source;

    private Because of = () => source.Width = ExpectedWidth;

    private It should_update_the_target = () => target.Width.ShouldEqual(ExpectedWidth);

Because we’re binding to the control’s data context the binding resolution is deferred until the target is measured.

Using the Binding Factory

Here are some examples of how to create Bindings using the Binding Factory.  Those that involve the data context are all deferred and those where the source is specified are all immediate.  An IDualChannel simply encapsulates both an IObservable and an IObserver so that data can flow in both directions (to and from the source).

Notice that you only need to specify type parameters when there is not enough information in the method’s parameters for the compiler to infer the types involved:

To the Data Context

IObservable<double> fromSource =

IObserver<double> toSource =

To a Reactive Property on the Data Context

IObservable<double> fromSource =
    BindingFactory.CreateOneWay<SourceObject, double>(SourceObject.WidthProperty);

IObserver<double> toSource =
    BindingFactory.CreateOneWayToSource<SourceObject, double>(SourceObject.WidthProperty);

IDualChannel<double> fromAndToSource =
    BindingFactory.CreateTwoWay<SourceObject, double>(SourceObject.WidthProperty);

To a Reactive Property on a specified Source

IObservable<double> fromSource =
    BindingFactory.CreateOneWay(source, SourceObject.WidthProperty);

IObserver<double> toSource =
    BindingFactory.CreateOneWayToSource(source, SourceObject.WidthProperty);

IDualChannel<double> fromAndToSource =
    BindingFactory.CreateTwoWay(source, SourceObject.WidthProperty);

To an INotifyPropertyChanged or CLR Property on the Data Context

IObservable<double> fromSource =
    BindingFactory.CreateOneWay<SourceObject, double>(o => o.Width);

IObserver<double> toSource =
    BindingFactory.CreateOneWayToSource<SourceObject, double>(o => o.Width);

IDualChannel<double> fromAndToSource =
    BindingFactory.CreateTwoWay<SourceObject, double>(o => o.Width);

To an INotifyPropertyChanged or CLR Property on a specified Source

IObservable<double> fromSource =
    BindingFactory.CreateOneWay(source, o => o.Width);

IObserver<double> toSource =
    BindingFactory.CreateOneWayToSource(source, o => o.Width);

IDualChannel<double> fromAndToSource =
    BindingFactory.CreateTwoWay(source, o => o.Width);

Clearing a Binding

To clear a binding simply call the ClearBinding() method on the relevant control, specifying the reactive property whose binding you want to clear:


Because an instance of ReactiveObject can only have one binding per property, calling the Bind() method replaces any existing binding.  Internally it calls ClearBinding() before attaching the new binding.

When a binding is cleared, its subscription to the source is automatically disposed.  This releases any attached event handlers (created automatically in order to listen to PropertyChanged events) which helps prevent memory leaks.  This is a great feature of Microsoft’s Reactive Extensions (Rx) that frees the developer from worrying about having to un-hook event handlers when an observer is no longer interested in the event.

Even though there can only be one binding at a time to an element’s property, you can still merge multiple observables together using any of the Rx combinators (Merge, Zip, CombineLatest etc) if you want your reactive property to listen to more than one source.


We hope that the binding system in XPF is simple to understand and easy to use.  Whilst the underlying property system in XPF is push based (rather than pull), we’ve strived to keep the development experience familiar to Silverlight and WPF developers.

The tight integration with Reactive Extensions makes it extremely flexible and powerful.  The statically typed nature of the binding and property system makes it intuitive, discoverable and refactoring friendly.  The absence of any magic strings means that there should be no run-time binding exceptions when a deferred binding cannot be resolved.  Binding to nested properties is currently not supported, but we plan to introduce this using the same strongly typed lambda expression syntax shown above.

Please download the latest build, play about with it and feedback to us!

Inside XPF Series:


Inside XPF: Reactive Properties

by Stuart Harris

Updated 2010-09-20: Reflects the removal of the generic type parameter TOwner from ReactiveProperty (starting Build 20).

Tetrahedral reflection by fdecomite

One of the design principles behind XPF has always been to provide a development experience that is familiar to Silverlight developers.  Silverlight’s Dependency Property plays an important role in making that development experience so good.  They enable most of the exciting functionality that both Silverlight and WPF bring to the table.

Pipes and Sockets

XPF introduces Reactive Properties that share some of the behaviour and familiarity of Dependency Properties and add the ability to behave like “sockets for pipes”.  Places where you can plug single- or bi-directional “pipes” that channel data asynchronously between your application’s objects.

Modern UI frameworks are heavily asynchronous so that stuff can happen in the background without making the UI unresponsive.  Silverlight helps enable this by providing asynchronous-only APIs for potentially “long-running” activities.  More and more, UI applications are built using objects that communicate with each other asynchronously.

Active Properties

Whilst regular C# Properties are mostly “passive”, Dependency Properties in Silverlight (and their sisters Attached Properties) are most definitely “active”.  Their “effective” values “depend” on their environment.  Instead of providing access to a single value in a backing field, they will actively seek out the most appropriate value for you at the time you request it.  Is an animation in progress?  Yes? Then that’s the value.  No?  Has the value been explicitly set?  OK, use that.  If not, is there a binding in place?  Is the binding one-way? OK, get the value from the source object.  Is there a relevant style to get the value from?  Can the value be inherited from an ancestor in the visual tree?  Also, if it’s an Attached Property it really belongs to an ancestor in the Visual Tree.

Each time a value is requested a complex workflow is instigated to work out what the value should be.  It’s great, it works really well and it’s behind all the Animation, Data Binding, Styling and Layout in Silverlight and WPF.

Reactive Properties

One of the most exciting things that’s happening in the world of software development at the moment is the evolution of Microsoft’s superb Reactive Extensions for .Net (Rx).  The team behind it discovered a duality between IEnumerable/IEnumerator and IObservable/IObserver which is not only extremely elegant, but also proves to be really useful in enabling pluggable, queryable, composable asynchronous pipes.

The same duality exists between Silverlight’s Dependency Properties and XPF’s Reactive Properties.  The former fetch the right value when asked to do so, the latter are given the right value when the time is right.  Data can be pushed to Reactive Properties through pipes – e.g. through a pipe from a data binding or through a pipe from an animation framework.  Data can also be pushed from the Reactive Property to any number of interested objects through pipes that can be joined, split, queried, filtered and processed in any number of ways.  All thanks to the genius of the guys behind Rx.

Show me some code

You’re probably familiar with the way in which Silverlight’s Dependency Properties are registered statically in a central registry.  XPF’s Reactive Properties are declared in a similar same way.  In the following code snippet, UIElement registers its Height Property with a default value of “Not a Number” and a call-back, which in this case, is just a static generic method that indicates to the property owner (UIElement) that it needs to re-measure when the value changes.  Notice that the generic Register method is typed for the property type (of double) allowing for strongly typed get/set accessors (no casting required):

public static readonly ReactiveProperty<double> HeightProperty =
    ReactiveProperty<double>.Register("Height", typeof(UIElement),
        double.NaN, ReactivePropertyChangedCallbacks.InvalidateMeasure);

public double Height
        return this.GetValue(HeightProperty);

        this.SetValue(HeightProperty, value);

Attached Properties are declared in exactly the same way – the only difference is that the property accessors (which are also strongly typed) are static:

public static readonly ReactiveProperty<double> LeftProperty = 
    ReactiveProperty<double>.Register("Left", typeof(Canvas),
        double.NaN, ReactivePropertyChangedCallbacks.InvalidateArrange);

public static double GetLeft(IElement element)
    if (element == null)
        throw new ArgumentNullException("element");

    return element.GetValue(LeftProperty);

public static void SetLeft(IElement element, double value)
    if (element == null)
        throw new ArgumentNullException("element");

    element.SetValue(LeftProperty, value);

Data Binding with Reactive Properties

The next post in the “Inside XPF” series will go into data binding in a lot more detail, but this excerpt from the BDD specs in XPF’s codebase shows how you can bind a property on a source (that implements INotifyPropertyChanged) to a Reactive Property on an element.  Notice how the binding is simply an IObservable of double.  You can plug anything that implements IObservable<double> into the property directly using the Bind() method.

public class when_a_binding_is_one_way
    private const double ExpectedWidth = 10d;

    private static TestBindingObject source;

    private static Border target;

    private Establish context = () =>
            source = new TestBindingObject(); // implements INotifyPropertyChanged
            target = new Border();

            IObservable<double> fromSource = BindingFactory.CreateOneWay(source, o => o.Width);
            target.Bind(UIElement.WidthProperty, fromSource);

    private Because of = () => source.Width = ExpectedWidth;

    private It should_update_the_target_property_with_the_correct_value =
        () => target.Width.ShouldEqual(ExpectedWidth);


Properties in XPF work natively with the new IObservable and IObserver interfaces in .Net 4.0, and their implementations in the Rx Framework.  This really improves the developer experience, because now you can connect up your UI properties to any asynchronous source.  Imagine being able to asynchronously bind your Reactive Properties directly to WebClient’s async Download methods?

Download the latest build and have a play!

Inside XPF Series:


XPF: Build 10 – Breaking Changes and System.Windows

by David Wynne

Prior to Build 10 all XPF controls ultimately inherited from System.Windows.DependencyObject and we used a wide variety of classes from within the System.Windows.* namespaces (Color, Rect, Size, Point etc).  Doing so saved us a lot of time, we didn’t need to recreate a lot of utility stucts and we were able to use Dependency Properties “for free” – which also meant we got to use Windows data binding and animation “for free” too.

As it turned out, free was not free as in beer.  Silverlight on WP7 hides a lot of useful information in Dependency Property that we need to make data binding work which resulted in some less than elegant workarounds.  There was also an “ingestion question” over whether the use of such classes from within an XNA application on WP7 would result in Marketplace ingestion failure.

As such we’ve decided to remove all our dependencies on System.Windows.* – this has a few downsides and a lot of upsides.

Downsides mean that there are quite a few breaking changes, but they’re nearly all easily resolved.  On Windows you no longer need to reference PresentationCore, PresentationFramework or WindowsBase – remove these references and recompile – you should find that the required equivalent classes are now in RedBadger.Xpf.  On WP7 there aren’t really any references to remove (you still need to reference System.Windows to access Application and ObservableCollection<T>) but you should be able to remove all “using System.Windows” statements from your code and recompile.

On the upside, XPF becomes a lot lighter and purer.  We’ve introduced a new and updated replacement for Dependency Properties – Reactive Properties.  Reactive Properties are strongly typed and use Reactive Extensions (Rx) to provide much of the same behaviours as Dependency Properties and a lot more besides.  Via IObservable<T> and IObserver<T> they drive the new data binding system with an improved, yet still familiar syntax.  We’ll be discussing Reactive Properties and data binding a lot more in our next few posts.

The other great upside is that Xbox support is now on the cards.  Rx has support for XNA 3.1 on the Xbox (as of build 1.0.2677.0) but we’ll need to wait until Rx for XNA 4.0 arrives and we can deploy XNA 4.0 applications to the Xbox before we can start testing.

The Getting Started post (and it’s sample code) have been updated to compile against Build 10.

As always – we want your feedback.


XPF Roadmap and Licensing

by Stuart Harris

You Are Here by joelogon

Throughout XPF’s beta we want to keep everyone in the loop so we thought we would set out a high-level roadmap to share our current plans.

These plans are not set in stone – we’re an agile shop and are always adapting to change as users give feedback about how the product is being used and make feature suggestions.

We really want your feedback!


We’ve yet to decide exactly what will constitute the version 1 release, but it’s fair to say that the vast majority of the planned features listed below will be there.

Done Planned (in order of priority) Future
UIElement (base class)
Panel (base class)
Grid (Auto/Pixel)
ItemsControl (with ItemTemplate)
Data Binding (one and two-way)

Grid: Star Grid Lengths
Grid: Row/Column Spanning
TextBlock: Default Font
ItemsControl: Control Template
ScrollViewer: Scroll Bars
Brush: Opacity
Pivot Control
Animation (Windows)
XAML Support
Control Templates
Visual State Manager


The finer details of XPF’s licensing model are still being worked on, but we’re really happy to be able to say that XPF will be free to use if you are an individual developing non-commercial or open source applications.


Once again, your feedback is really important to us.  If there’s a feature you don’t see listed, or want one feature developed first over another, then let us know.  We’re also really interested to see how XPF is being used, so if you’ve got any examples then please do get in contact – we’re already hearing some great stories.


XPF and Reactive Extensions for .Net (Rx)

by David Wynne

Update 2010-09-20: As of Build 19 XPF uses version 1.0.2698.104 of Rx as the problem referred to below has been addressed.

image XPF uses Reactive Extensions for .Net (Rx) internally to handle user input and eventing.  If you’re developing on Windows Phone 7 everything will work just fine, Rx comes with the Phone assemblies.  If you’re working on the desktop, you’ll need to install Rx in order to use XPF in your solution.

As of Build 6, XPF uses version 1.0.2617.0 of Rx which is the latest “but one” release of Rx.  The latest build of Rx (1.0.2677.0) indirectly takes a dependency on System.Web which isn’t in the .Net 4.0 Client Profile.  If we were to use to that version it would require all Windows XNA applications built with XPF to target the full .Net 4.0 profile, which is not the default for XNA applications.

It looks like this maybe addressed in a future version of Rx, so we’ll move to the latest version as soon as this problem is addressed by the Rx team.

For now, to avoid confusion you’ll need to make sure you have version 1.0.2617.0 for .Net 4 of Rx installed (multiple versions can be installed side-by-side).  You can download it from the Rx Team Blog, or by using this direct link:

Thanks to @fahadsuhaib for pointing out we were using an older version in Build 5.