Thursday Night

Paul Betts’s personal website / blog / what-have-you

ReactiveUI Link Roundup

View Comments

If you’re new to ReactiveUI and you’re looking for information on how it works, I’ve written lots of blog posts on the topic. Here’s some of the best ones:


I make sure to post all of my RxUI-related posts under the Reactive Extensions category on my blog, and I also usually tweet about them via Twitter, my handle there is @xpaulbettsx.

Where can I get help?

If you’re trying out ReactiveUI and something doesn’t work right, or it’s not clear how to go about doing something, send me an Email. Another good place to get support is the ReactiveUI Google Group.

Written by Paul Betts

January 17th, 2011 at 12:25 pm

ReactiveXaml is now ReactiveUI 2.0!

View Comments

What does ReactiveUI do?

ReactiveUI is a M-V-VM framework like MVVM Light or Caliburn.Micro, that is deeply integrated with the Reactive Extensions for .NET. This allows you to write code in your ViewModel that is far more elegant and terse when expressing complex stateful interactions, as well as much simpler handling of async operations. Check out this video for an overview:

YouTube Preview Image

Why the name change? I liked ReactiveXaml

The main reason I decided to change the name, is that many of the classes in ReactiveUI are useful outside of WPF and Silverlight, especially with a new library that I’m working on called ReactiveUI.Serialization (not quite ready yet!) Observable objects and collections are quite useful in non-XAML domains as well, so I want to broaden the scope a bit. For example, I think a lot of these classes could be pretty useful for building ASP.NET MVC ViewModels as well! I think ReactiveUI’s shortened name of RxUI looks better too :)

Where can I find the library?

On NuGet! The best way to install ReactiveUI for a project is by installing the ReactiveUI package for WPF/Silverlight projects, or ReactiveUI-WP7 for Windows Phone 7 projects.

If NuGet isn’t your thing, you can also find the binaries on the Github page: ReactiveUI

Where can I see a sample?

A sample project for WPF 4.0 that includes everything you need to see how it works is on the Github page: ReactiveUI 2.0 It includes a small sample app, the RxUI binaries, and some sample test cases.

Version 2.0 means breaking changes

ReactiveUI uses semantic versioning (mostly), which means that version 2.0 contains breaking changes from the 1.x series. The biggest one is the namespace change and split – several classes that have dependencies on WPF/Silverlight are now moved into the “ReactiveUI.Xaml” assembly/namespace. Fixing this is usually pretty straightforward. Most of the other breaking changes are name changes and shuffling some parameter names around, especially in ReactiveCommand and ReactiveAsyncCommand.

Here’s one big change that is more subtle – in previous versions of ReactiveUI, the “Changed” Observable would give you “Sender”, “PropertyName”, and “Value”, but Value would be null on certain Observables and non-null on others, in a completely arbitrary way. In ReactiveUI 2.0, the rule is, if you explicitly ask for the property by-name (i.e. via ObservableForProperty), the Value will be set. However, there is also a GetValue() method on ObservedChange and a Value() method on IObservable that will get the value given any ObservedChange.

New features in 2.0

  • ReactiveUI now has a simple, Rx-enabled Message Bus, inspired by MVVM Light’s Message Bus
  • A new set of extension methods to help writing unit tests (ReactiveUI.Testing) – write unit tests that simulate concurrency without using Thread.Sleep, and get the same results every run
  • Unit test detection now correctly works with Silverlight
  • A new async cache class that supports Silverlight, and an extension method to easily integrate it to existing code (MemoizedSelectMany). Easily turn concurrent web calls into memoized, rate-throttled web calls
  • Object validation is vastly improved in this release – many bugs fixed and is more performant.
  • The same async cache class is also used in ReactiveAsyncCommand to properly support memoization
  • CreateDerivedCollection() now works with ObservableCollection, making it easier to create ViewModels from existing non-RxUI code
  • Easily get an Observable from a DependencyProperty (ObservableFromDP), even in Silverlight and WP7
  • Cleaner syntax for creating properties based on Observables
  • Intellisense documentation for all classes
  • ReactiveCollection is vastly improved – it now supports tracking object property changes (i.e. it’s now easy to track “Tell me when items are added/removed, or when a property changes on any of the objects in this list”)
  • RxUI now uses the latest Rx.NET release (the “Christmas Release”)
  • The RxUI core DLL is no longer dependent on any WPF binaries, so it is more palatable to integrate into non-WPF projects.

Hey, why is this version

Here’s some advice to other developers – if you’re ever considering, “Oh, I’ll just change this one thing right before I release, it’ll be fine!”, don’t. Here’s the last-minute bug that I introduced that completely borks v2.0.0.0. :: sigh ::

Building the project:

Building the project requires having quite a few products installed – to build a full release, you need:

  • Visual Studio 2010
  • Pex / Moles
  • Code Contracts for .NET
  • Expression Blend 4.0
  • Silverlight 4.0 Development Tools
  • Windows Phone 7 Development Tools

That being said, if you’re only interested in ReactiveUI core, you only need VS2010 Professional – the other projects can simply be unloaded. Clone the source from GitHub, or download the source code release as a Zip file (though I highly recommend the former).

Written by Paul Betts

January 15th, 2011 at 10:33 pm

ReactiveXaml Series: QueuedAsyncMRUCache – the async version of MemoizingMRUCache

View Comments

A thread-safe, asynchronous MemoizingMRUCache

As we saw in a previous entry, MemoizingMRUCache is great for certain scenarios where we want to cache results of expensive calculations, but one disadvantage is that it is fundamentally a single-threaded data structure: accessing it from multiple threads, or trying to cache the results of several in-flight web requests at the same time would result in corruption. QueuedAsyncMRUCache solves all of these issues, as well as gives us a new method called AsyncGet, which returns an IObservable. This IObservable will fire exactly once, when the async command returns.

What places would I actually want to use this class? Here’s a motivating example: you’re writing a Twitter client, and you need to fetch the profile icon for each message – a naive foreach loop would be really slow, and even if you happened to write it in an asynchronous fashion, you would still end up fetching the same image potentially many times!

Using IObservable as a Future

One of the things that an IObservable encapsulates is the idea of a Future, described simply as the future result of an asynchronous operation. The pattern is implemented via an IObservable that only produces one element then completes. Using IObservable as a Future provides a few handy things:

  • IObservables let us block on the result if we want, via Observable.First().
  • IObservables have built-in error handling via OnError, so we can also handle the case where something goes pear-shaped.
  • We can easily group several IObservables together via Observable.Merge and wait for any (or all) of them.

A difficult problem – preventing concurrent identical requests

Furthermore, QueuedAsyncMRUCache solves a tricky problem as well: let’s revisit the previous example. As we walk the list of messages, we will asynchronously issue WebRequests. Imagine a message list where every message is from the same user:

For the first item, we’ll issue the WebRequest since the cache is empty. Then, we’ll go to the 2nd item – since the first request probably hasn’t completed, we’ll issue the same request again. If you had 50 messages and the main thread was fast enough, you could end up with 50 WebRequests for the same file!

What should happen? When the 2nd call to AsyncGet occurs, we need to check the cache, but we also need to check the list of outstanding requests. Really, for every possible input, you can think of it being in one of three states: either in-cache, in-flight, or brand new. QueuedAsyncMRUCache ensures (through a lot of code!) that all three cases are handled correctly, in a thread-safe manner.

Written by Paul Betts

August 23rd, 2010 at 11:43 pm

The case of the disappearing OnLoad exception – user-mode callback exceptions in x64

View Comments

For the impatient, you can skip to the end of the article to see what you should do about disappearing exceptions in desktop applications

The problem – why doesn’t this crash?

If you’ve got a 64-bit OS on your machine, try the following: open up Visual Studio 2010 and create a new WinForms project. Add an OnLoad event handler and paste in the following code:

namespace WindowsFormsApplication1
    public partial class Form1 : Form
        public Form1()

        private void OnLoad(object sender, EventArgs e)
            throw new Exception("Hey, where’d I go?");

    static class Program
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        static void Main()
            Application.Run(new Form1());

            MessageBox.Show("We should never get here");

Run the app – it succeeds! The exception we threw just disappeared into the ether, and the app just went on its merry way. A lot of people think this is a CLR bug or a WinForms bug, but it actually happens everywhere – you can trigger this using WinForms, WPF, and also in MFC / straight Win32. This is a complicated design decision in ntdll / NT kernel that I worked on for Vista and Windows 7, and it’s important to understand if you’re writing desktop applications on Windows. But before I can explain how it all works, we’ll learn some about exceptions in NT.

What is an SEH exception?

Different programming languages all implement their own notion of software exceptions differently, with different semantics (some like C# offer keywords like ‘finally’, for example, and others like VB.NET allow you to run a filter function on thrown exceptions to decide whether to catch them). However, Windows has its own notion of exceptions, called Structured Exception Handling. Almost every language-specific exception framework including C++ and .NET exceptions are really SEH exceptions on Windows.

This concept is built into the NT kernel – remember, that not all exceptions are traps (i.e, invoked by a ‘throw’ statement); exceptions are also generated by the hardware. When you run that *((void*)0x0) = 0x42; statement, the CPU attempts to walk the page tables looking for that memory mapping; when it fails, the CPU raises a hardware page fault exception, and the OS has a chance to take over. The OS will realize that this address is bogus, and it propagates that exception back to the application as an SEH exception with the code STATUS_ACCESS_VIOLATION.

The moral I’m trying to express is, that all of these program crashes like a Null pointer or a divide-by-zero are really all SEH exceptions. You could catch that exception and in fact, that’s exactly how the CLR’s NullReferenceException works – it’s really a reworded access violation, verified to point to NULL. When an exception is thrown, it walks up the stack looking for a handler – when it finally runs out of stack entries to traverse, UnhandledExceptionFilter is invoked, and normally that sends a signal to WER to come clean up the mess.

Here’s the reason that you probably shouldn’t implement exceptions yourself if you’re a language implementer – SEH exceptions are the only ones that understand how to traverse the user-mode / kernel-mode boundary (i.e. think about what happens when you throw an exception inside a user-mode APC for example – the exception has to go through kernel-mode to get back to your WinMain).

How come this doesn’t happen all the time?

Here’s why this seems to happen only on certain window messages – remember that window messages can originate from different sources, anyone(*) can queue a message to a window. However, certain window messages are directly sent via win32k.sys (the most notable one being WM_CREATE) as a direct synchronous result of a user-mode call.

Your app calls CreateWindow(); this results in a system call to NtCreateWindow. This syscall ends up going down to win32k.sys, who does the work of actually creating the window. None of the work is deferred, it’s all done in the context of the running user thread; as part of the work to create and show the window, win32k must call the app’s WndProc function. We’ve went from user mode to kernel mode, and now we have to come back to user mode, all in the same thread stack. Here’s what it looks like:

00 KERNELBASE!RaiseException+0x39
01 clr!RaiseTheExceptionInternalOnly+0x363
02 clr!IL_Throw+0x146
03 WindowsFormsApplication1!WindowsFormsApplication1.Form1.OnLoad+0x70
04 System_Windows_Forms_ni!System.Windows.Forms.Form.OnLoad+0x1a9
05 System_Windows_Forms_ni!System.Windows.Forms.Control.CreateControl+0x1c4
06 System_Windows_Forms_ni!System.Windows.Forms.Control.CreateControl+0x24
07 System_Windows_Forms_ni!System.Windows.Forms.Control.WmShowWindow+0xd8
08 System_Windows_Forms_ni!System.Windows.Forms.Control.WndProc+0x3dd
09 System_Windows_Forms_ni!System.Windows.Forms.Form.WndProc+0x243
0a System_Windows_Forms_ni!System.Windows.Forms.NativeWindow.Callback+0x16c
0b System_Windows_Forms_ni!DomainBoundILStubClass.IL_STUB_ReversePInvoke+0x50
0c clr!UMThunkStubAMD64+0x77
0d USER32!UserCallWinProcCheckWow+0x1ad
0e USER32!DispatchClientMessage+0xc3
0f USER32!__fnDWORD+0x2d
10 ntdll!KiUserCallbackDispatcherContinue
11 USER32!ZwUserShowWindow+0xa
12 clr!DoNDirectCall__PatchGetThreadCall+0x7b
13 System_Windows_Forms_ni!DomainBoundILStubClass.IL_STUB_PInvoke+0x42
14 System_Windows_Forms_ni!System.Windows.Forms.Control.SetVisibleCore+0x179
15 System_Windows_Forms_ni!System.Windows.Forms.Form.SetVisibleCore+0x25d
16 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner+0x1dc
17 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoop+0x81
18 WindowsFormsApplication1!WindowsFormsApplication1.Program.Main()+0x57

Frame 10 and 11 are the ones I’m talking about – we disappeared into the syscall, then reappear in userspace via KiUserCallbackDispatcherContinue, then we showed up into OnLoad in frame 3. SEH will now walk the stack back up but will hit a brick wall at KiUserCallbackDispatcherContinue. For complicated reasons, we cannot propagate the exception back on 64-bit operating systems (amd64 and IA64). This has been the case ever since the first 64-bit release of Server 2003. On x86, this isn’t the case – the exception gets propagated through the kernel boundary and would end up walking the frames back until it ended up at WindowsFormsApplication1.Program.Main().

When this happens, there are only two things we can sanely do: either make the exception disappear, or kill the application: rethrow the exception as noncontinuable, similar to the CLR’s StackOverflowException. Your catch blocks and finallys still run, but any attempts to catch the exception are ignored. The kernel architects at the time decided to take the conservative AppCompat-friendly approach – hide the exception, and hope for the best.

Why would I want to crash my own application?

In a small application, you can sometimes get away with eating the exception – if you can, great! However, most of the time you’re not so lucky; since SEH was in the middle of unwinding the stack and processing the exception then suddenly jumped to another location, the application is usually in a very inconsistent weird state when the call comes back, as if you just suddenly longjmp()’ed to another place. The end result for large apps is chaos – a simple AV turns into an difficult to debug application state corruption – if you’re a developer, you’ll pull your hair out wondering how your structures ended up in such a bizarre state. This also makes it very difficult to use the crash reports from WER or write your own error reporting code, since you’ll never see the true crash, only a later random one that resulted from the corrupted state.

The situation on Server 2003 and Vista

On Server ’03, XP64 (a rebranded Server ’03) and Vista, we kept the swallow exception behavior on both native x64 applications and WOW64 applications (32-bit programs running on a 64-bit OS), in an attempt to keep programs working. However, this was never an ideal solution – we needed a better way to cater to both modern applications by crashing and giving good bug reports, as well as to legacy applications that just happened to work correctly.

Windows 7 fixes this…kind of

The solution? In Windows 7, when a native x64 application crashes in this fashion, the Program Compatibility Assistant is notified. If the application doesn’t have a Windows 7 Manifest, we show a dialog telling you that PCA has applied an Application Compatibility shim. What does this mean? This means, that the next time you run your application, Windows will emulate the Server 2003 behavior and make the exception disappear. Keep in mind, that PCA doesn’t exist on Server 2008 R2, so this advice doesn’t apply.

What does this mean to you as a developer? This means, if you’re writing a new application, you always want to have a Win7-compatible manifest. Using a Win7 manifest tells Windows not to treat you like an older application and always use the latest OS features.

Completing the story with KB976038

I called out in the Win7 section that this applies to native x64 applications – well, what about 32-bit applications (WOW64 processes)? Unfortunately in Win7 RTM, WOW64 applications still have the Server ’03 behavior: exceptions are always swallowed. However, if you install this hotfix from Microsoft, WOW64 will now act just like x64 on Windows 7 – Win7-manifested x86 applications will crash, just like their x64 counterparts.

This fix also gets you more ways to control when we swallow or rethrow user-mode callback exceptions: first, for debugging purposes only, this fix adds a way to control the behavior via Image File Execution Options. You can enable/disable this option system-wide, or per-application (via the EXE name). I want to mention again though, that this option is for developer machines. If you set this key in an installer, you are Doing it Wrong and will make me sad.

Another way that you can enable/disable exception swallowing is via a new public API in Kernel32.dll – since this won’t be available in the SDK headers until Win7 SP1, you’ll have to dynamically invoke the API call via LoadLibrary and GetProcAddress. Here’s the definitions of these functions:

// If this flag is set, the exception will be *swallowed* (i.e. the Server ’03
// behavior)


    __in DWORD dwFlags

    __out LPDWORD lpFlags

So, the best future-proof way to call this function is:

DWORD dwFlags;
if (GetProcessUserModeExceptionPolicy(&dwFlags)) {
    SetProcessUserModeExceptionPolicy(dwFlags & ~PROCESS_CALLBACK_FILTER_ENABLED); // turn off bit 1

Hey, there’s a Vista package too

On Vista, the story’s a bit different: since PCA doesn’t have the proper support on Vista, the hotfix will add this behavior only for applications (either native or WOW64) who specifically ask for it via the public API or the IFEO key. Since this is a hotfix for an older, stable operating system, the hotfix tries to be more conservative so existing apps aren’t broken.

In Summary – ways to control user-mode exceptions

Here’s the tl;dr; version of this article:

  • If you’re writing desktop applications, install this hotfix from Microsoft on all your development machines until Win7 SP1 comes out.
  • Mark all your new applications as Win7-compatible.
  • If the manifest doesn’t work for you for some reason, or you’re shipping for Vista, try to call the public API via GetProcAddress.

Written by Paul Betts

July 20th, 2010 at 11:42 pm

VS2010 Snippets for ReactiveXaml

View Comments

One of the folks using RxXaml is our intrepid intern, Roberto Sonnino (he’s the one who came up with the short name RxXaml!) – he’s created some handy snippets that will expand out to the standard forms of a read-write ReactiveObject property, as well as a property backed by ObservableAsPropertyHelper. I’m personally against snippets since I want typing extra code to cost me personally as much as possible, encouraging me to be more general and brief! However, I think in this case it’s a good idea – here are the snippets:

Written by Paul Betts

July 20th, 2010 at 12:35 am

ReactiveXaml series: Using MemoizingMRUCache

View Comments

Memoization and Caching

One thing that is useful in any kind of programming is having a look-up table so that you don’t have to spend expensive calls to fetch the same data that you just had recently, since fetching the data and passing it around via parameters often gets ugly. A better way is to use a cache – store values we’ve fetched recently and reuse them. So, a na├»ve approach would be to store the data off in a simple Dictionary. This might work for awhile, but you soon realize as Raymond Chen says, “Every cache has a cache policy, whether you know it or not.” In the case of a Dictionary, the policy is unbounded – an unbounded cache is a synonym for ‘memory leak’.

To this end, one of the things that comes with ReactiveXaml is a class called MemoizingMRUCache. As its name implies, it is a most recently used cache – we’ll throw away items whose keys haven’t been requested in awhile; we’ll keep a fixed limit of items in the cache, unlike other approaches involving WeakReference that keep references to items only if they’re used on some other thread at the time. Since most desktop / Silverlight applications aren’t so massively multithreaded as a web application, using a WeakReference approach means we’ll just get constant cache misses.

Using MemoizingMRUCache

Really when it comes down to it, you can just think of MemoizingMRUCache as just a proxy for a function – when you call Get, it’s going to invoke the function you provided in the constructor. One thing that’s important to understand with this class, is that your function must be a function in the mathematical sense – i.e. the return value for a given parameter must always be identical. Another thing to remember is that this class is not implicitly thread-safe – unlike QueuedAsyncMRUCache, if you use it from multiple threads, you have to protect it via a lock just like a Dictionary or a List.

Here’s a motivating sample:

// Here, we’re giving it our "calculate" function – the ‘ctx’ variable is
// just an optional parameter that you can pass on a call to Get.
var cache = new MemoizingMRUCache[int, int]((x, ctx) => {
    Thread.Sleep(5*1000);     // Pretend this calculation isn’t cheap
    return x * 100;
}, 20 /*items to remember*/);

// First invocation, it’ll take 5 seconds
>>> 1000

// This returns instantly
>>> 1000

// This takes 5 seconds too
>>> 1500

Maintaining an on-disk cache

MemoizingMRUCache also has a feature that comes in handy in certain scenarios: when a memoized value is evicted from the cache because it hasn’t been used in awhile, you can have a function be executed with that value. This means that MemoizingMRUCache can be used to maintain on-disk caches – your Key could be a website URL, and the Value will be a path to the temporary file. Your OnRelease function will delete the file on the disk since it’s no longer in-use.

Some other useful functions

  • TryGet – Attempt to fetch a value from the cache only
  • Invalidate – Forget a cached key if we’ve remembered it and call its release function
  • InvalidateAll – Forget all the cached keys and start from scratch

Written by Paul Betts

July 13th, 2010 at 10:48 pm

ReactiveXaml series: Implementing search with ObservableAsPropertyHelper

View Comments

Implementing an auto-search TextBox using Rx and ReactiveXaml

One of the most important classes in ReactiveXaml called ObservableAsPropertyHelper is a class that allows you to take an IObservable and convert it into a read-only, change notifying property. This class is really useful for exposing the results of your code (i.e. the “output”). This class makes it easy to complete the scenario that was described in the previous blog post about ReactiveAsyncCommand. One of the cool things about ObservableAsPropertyHelper, is that it guarantees that it will run notifications on the UI thread via the Dispatcher so that you don’t have to think about what thread the observable notification came in on.

The sample app

Click on the image to download the sample project.

Going through the code

First, let’s look at our main data item – a Flickr search result item. Since we will never change these objects, we don’t need any INotifyPropertyChanged goo, just regular old auto-properties:

public class FlickrPhoto {
    public string Title { get; set; }
    public string Description { get; set; }
    public string Url { get; set; }

Now, the app data model – there’s two real bits; the current search text, and the List of FlickrPhoto results. In ReactiveXaml, all of this code below is boilerplate – these code chunks are just some stuff to memorize or put into a snippet and never look at it again. Note: once again because of a syntax highlighting glitch, generics are using [] instead of < >

public class AppViewModel : ReactiveValidatedObject
    // This is the canonical way to make a read-write property

    string _SearchTerm;
    public string SearchTerm {
        get { return _SearchTerm; }
        set { this.RaiseAndSetIfChanged(x => x.SearchTerm, value); }

    // This is the canonical way to make a read-only property whose value
    // is backed by an IObservable

    ObservableAsPropertyHelper[List[FlickrPhoto]] _Photos;
    public List[FlickrPhoto] Photos {
        get { return _Photos.Value; }

    ObservableAsPropertyHelper[Visibility] _SpinnerVisibility;
    public Visibility SpinnerVisibility {
        get { return _SpinnerVisibility.Value; }

    public ReactiveAsyncCommand ExecuteSearch { get; protected set; }

Now here’s the interesting part

Our goal is to write a search box which automatically issues searches in the background as the user types, similar to what most browsers do with the address bar. However, there are a number of tricky aspects to this:

  • We don’t want to issue too many requests, especially when the user is still typing, so wiring something directly to KeyUp would be lousy.
  • Don’t issue queries for empty strings, and don’t issue the same query 2x (for example, if the user types “foo”, then quickly hits Backspace, then retypes ‘o’, we should realize that we already have the right results)
  • The delay should be consistent, so having a global timer won’t work because sometimes the user will hit the key right before the timer fires, so the delay will vary wildly between the max time and instantaneous.

Implementing this properly using traditional methods would be absolutely awful. Here’s the code on how we do it, and it’s 5 lines in the constructor:

public AppViewModel()
    ExecuteSearch = new ReactiveAsyncCommand(null, 0);

    // Take the inflight items and toggle the visibility

    var should_spin = ExecuteSearch.ItemsInflight.Select(x => x > 0 ? Visibility.Visible : Visibility.Collapsed);

    // This was described last time too, we actually do the async function
    // here and RegisterAsyncFunction will return an IObservable which
    // gives us the output, one item per invocation of ExecuteSearch.Execute

    var results = ExecuteSearch.RegisterAsyncFunction(
        term => GetSearchResultsFromFlickr((string)term));

    // Here’s the awesome bit – every time the SearchTerm changes
    // throttled to every 800ms (i.e. drop changes that are happening
    // too quickly). Grab the actual text, then only notify on unique
    // changes (i.e. ignore "A" => "A"). Finally, only tell us when
    // the string isn’t empty. When *all* of those things are true,
    // fire ExecuteSearch and pass it the term.

    this.ObservableForProperty[AppViewModel, string]("SearchTerm")
        .Select(x => x.Value).DistinctUntilChanged()
        .Where(x => !String.IsNullOrWhiteSpace(x))

    // This code is also boilerplate, it’s the standard way to take our
    // observable and wire it up to the property, giving it an initial
    // value.

    _SpinnerVisibility = new ObservableAsPropertyHelper[Visibility](
        should_spin, x => RaisePropertyChanged("SpinnerVisibility"), Visibility.Collapsed);

    _Photos = new ObservableAsPropertyHelper[List[FlickrPhoto]](
        results, _ => RaisePropertyChanged("Photos"));

Here’s the code that actually does the work as an aside, it’s not nearly as pretty:

// If you don’t understand this code, don’t worry about it, I just got lazy.
// We’re just hack-parsing the RSS feed and grabbing out title/desc/url and
// newing up the list of FlickrPhotos while blatantly abusing Zip.

public static List[FlickrPhoto] GetSearchResultsFromFlickr(string search_term)
    var doc = XDocument.Load(String.Format(CultureInfo.InvariantCulture,
    if (doc.Root == null)
        return null;

    var titles = doc.Root.Descendants("{}title")
        .Select(x => x.Value);
    var descriptions = doc.Root.Descendants("{}description")
        .Select(x => HttpUtility.HtmlDecode(x.Value));
    var items = titles.Zip(descriptions,
        (t, d) => new FlickrPhoto() { Title = t, Description = d }).ToArray();

    var urls = doc.Root.Descendants("{}thumbnail")
        .Select(x => x.Attributes("url").First().Value);

    var ret = items.Zip(urls, (item, url) => { item.Url = url; return item; }).ToList();
    return ret;

Written by Paul Betts

July 5th, 2010 at 5:26 pm

ReactiveXaml series: A Sample MVVM application

View Comments

A Sample App makes understanding ReactiveXaml way easier

I used this application to help guide the API design around ReactiveXaml, and I think it’s a good illustration on how to use this library to write WPF applications. The original goal of it was to teach WPF to folks, so it has a ton of documentation in the comments – it almost is “blogging via code”, and I think it’s a really interesting way to express ideas, calling back somewhat to Knuth’s ideas of Literate Programming

Our sample app helps us make a list of Awesome People

Make sure to read the code!

A lot of people who originally saw this sample ran it, saw that it didn’t really do anything interesting, then forgot about it. The app itself is boring, the code is what’s important! Read through it, there are lots of “essays” scattered throughout the source code, they all start with the tag “COOLSTUFF” – searching for it will help you find guidance on Rx, MVVM, as well as things like layout and bindings.

This dialog shows validation, async web requests, and a clever use of Flickr

Where’s the code again?

It’s at the ReactiveXaml repository on Github – if any of you want to check this out but have trouble getting Git to work, let me know via Email at or Email the mailing list and I’ll help you out.

Written by Paul Betts

June 27th, 2010 at 8:50 pm

ReactiveXaml Series: ReactiveAsyncCommand

View Comments


If you’ve done any WPF programming that does any sort of interesting work, you know that one of the difficult things is that if you do things in an event handler that take a lot of time, like reading a large file or downloading something over a network, you will quickly find that you have a problem: during the blocking call, the UI turns black. Silverlight heads this off at the pass – you can’t even do blocking operations at all.

So you say, “Oh, I’ll just run it on another thread!” Then, you find the 2nd tricky part – WPF and Silverlight objects have thread affinity. Meaning, that you can only access objects from the thread that created them. So, at the end of the computation when you go to run textBox.Text = results;, you suddenly get an Exception.

Dispatcher.BeginInvoke solves this

So, once you dig around on the Internet a bit, you find out the pattern to solve this problem involves the Dispatcher:

void SomeUIEvent(object o, EventArgs e)
    var some_data = this.SomePropertyICanOnlyGetOnTheUIThread;
    var t = new Task(() => {
        var result = doSomethingInTheBackground(some_data);
        Dispatcher.BeginInvoke(new Action(() => {
            this.UIPropertyThatWantsTheCalculation = result;

We use this pattern a lot, let’s make it more succinct

So, the idea of ReactiveAsyncCommand is that many times, when we run a command, we often are just:

  1. The command executes, we kick off a thread
  2. We calculate something that takes a long time
  3. We take the result, and set a property on the UI thread, using Dispatcher

Because we encapsulate the pattern, we can get other stuff for free

ReactiveAsyncCommand attempts to capture that pattern, and makes certain things easier. For example, you often only want one async instance running, and the Command should be disabled while we are still processing. Another common thing you would want to do is, display some sort of UI while an async action is running – something like a spinner control or a progress bar being displayed.

Since ReactiveAsyncCommand derives from ReactiveCommand, it does everything its base class does – you can use it identically, and the Execute IObservable tells you when workitems are queued.. What ReactiveAsyncCommand does that would be hard to do with ReactiveCommand directly, is that it has code built-in to automatically keep track of in-flight workitems.

The first pattern – running an Action in the background

Here’s a simple use of a Command, who will run a task in the background, and only allow one at a time (i.e. its CanExecute will return false until the action completes)

var cmd = new ReactiveAsyncCommand(null, 1 /*at a time*/);

cmd.RegisterAsyncAction(i => {
    Thread.Sleep((int)i * 1000); // Pretend to do work

cmd.Execute(5 /*seconds*/);
cmd.CanExecute(5)// False! We’re still chewing on the first one.

Putting it all together

Remember, ReactiveXaml is a MVVM framework – to fully demonstrate calculating a value and displaying it in the UI, it’s easiest to make a very simple MVVM application. Here’s the XAML, and the basic class:

<window x:Class="RxBlogTest.MainWindow"
        x:Name="Window" Height="350" Width="525">

    <grid DataContext="{Binding ViewModel, ElementName=Window}">
        <stackpanel HorizontalAlignment="Center"  VerticalAlignment="Center">
            <textblock Text="{Binding DataFromTheInternet}" FontSize="18"/>

            <button Content="Click me!" Command="{Binding GetDataFromTheInternet}"
                    CommandParameter="5" MinWidth="75" Margin="0,6,0,0"/>


And the codebehind:

using System;
using System.Threading;
using System.Windows;
using ReactiveXaml;

namespace RxBlogTest
    public partial class MainWindow : Window
        public AppViewModel ViewModel { get; protected set; }
        public MainWindow()
            ViewModel = new AppViewModel();

    public class AppViewModel : ReactiveValidatedObject
        ObservableAsPropertyHelper[string] _DataFromTheInternet;
        public string DataFromTheInternet {
            get { return _DataFromTheInternet.Value; }

        public ReactiveAsyncCommand GetDataFromTheInternet { get; protected set; }

This is a simple MVVM application, whose ViewModel has two items – a Command called “GetDataFromTheInternet”, and a place to store the results, a property called “DataFromTheInternet”. I’ll describe ObservableAsPropertyHelper later, but you can think of it as a class that “Remembers the latest value of an IObservable”.

Using ReactiveAsyncCommand

The difference between RegisterAsyncAction and RegisterAsyncFunction is the return value. The latter function returns an IObservable representing the results that will be returned. For async calls, you can often think of IObservable as a Future Result, that is, a “promise” of a result (or an Exception if something goes pear-shaped). In this case, our IObservable represents the “output” pipeline, and will produce results every time someone fires the command, one per Execute().

Here’s how we actually implement the async function, in the ViewModel constructor.

public AppViewModel()
    GetDataFromTheInternet = new ReactiveAsyncCommand(null, 1 /*at a time*/);

    // This function will return a "stream" of results, one per invocation
    // of the Command

    var future_data = GetDataFromTheInternet.RegisterAsyncFunction(i => {
        Thread.Sleep(5 * 1000)// This is a pretend async query
        return String.Format("The Future will be {0}x as awesome!", i);

    // OAPH will "watch" future_data, and raise property changes when new values
    // come in. It’ll also provide the latest result that came in.
    _DataFromTheInternet = new ObservableAsPropertyHelper<string>(future_data,
        x => RaisePropertyChanged("DataFromTheInternet"));

Why is this cool?

Notice what I didn’t have to do here: I didn’t have to use any sort of explicit async mechanism like a Task or a new Thread, I didn’t have to marshal data back to the UI thread using Dispatcher.BeginInvoke, and my code reads way more like a simple, single-threaded application again, instead of chaining async invocations. Stuff like this is why I’m really excited about some of the concepts in ReactiveXaml.

Furthermore, there’s something else here that’s very motivating: testability. Using Dispatcher.BeginInvoke means that we’re assuming that a Dispatcher exists and works. If you’re in a unit test runner, this isn’t true. Which means, your Commanding code if you’re using other MVVM frameworks that don’t handle this isn’t testable. ReactiveXaml automatically detects whether you are in a test runner, and changes its default IScheduler to not use the Dispatcher. Test code still works, without hacking your ViewModel code at all.

Where’s the Code?

Get the code here: Also, I’m too lazy to correct the typo in the namespace, bt it doesn’t matter. Thoughts? Comments? Ideas?

Written by Paul Betts

June 27th, 2010 at 7:18 pm

ReactiveXaml series: ReactiveCommand

View Comments

What is ReactiveCommand

ReactiveCommand is an ICommand implementation that is simultaneously a RelayCommand implementation, as well as some extra bits that are pretty motivating. Let’s jump right into the first example:

// This works just like Josh Smith’s RelayCommand
var cmd = new ReactiveCommand(_ => true, Console.WriteLine);
>> true


Well that’s boring, where’s the fun stuff??

However, here’s where it gets interesting – we can also provide IObservable<bool> as our CanExecute. For example, here’s a command that can only run when the mouse is up (pretend the square brackets are < > – there’s a bug in the syntax highlighting):

var is_mouseup = Observable.Merge(
        Observable.FromEvent[MouseButtonEventArgs](window, "MouseDown")
                  .Select(_ => false),
        Observable.FromEvent[MouseButtonEventArgs](window, "MouseUp")
                   .Select(_ => true),

    var cmd = new ReactiveCommand(is_mouseup, Console.WriteLine);

Or, how about a command that can only run if two other commands are disabled:

// Pretend these were already initialized to something more interesting
var cmd1 = new ReactiveCommand(null, null);
var cmd2 = new ReactiveCommand(null, null);

var can_exec = cmd1.CanExecuteObservable.CombineLatest(cmd2.CanExecuteObservable,
                     (lhs, rhs) => !(lhs && rhs));
var new_cmd = new ReactiveCommand(can_exec, Console.WriteLine);

One thing that’s important to notice here, is that the command’s CanExecute updates immediately, instead of relying on CommandManager.RequerySuggested. If you’ve ever had the problem in WPF or Silverlight where your buttons don’t reenable themselves until you switch focus or click them, you’ve seen this bug. Using an IObservable means that the Commanding framework knows exactly when the state changes, and doesn’t need to requery every command object on the page.

What about Execute?

This is where ReactiveCommand’s IObservable implementation comes in – ReactiveCommand itself can be observed, and it provides new items whenever Execute is called (the items being the parameter passed into the Execute call). This means, that Subscribe can act the same as the Execute Action, or we can actually get a fair bit more clever. For example:

var cmd = new ReactiveCommand(x => x is int, null);
cmd.Where(x => ((int)x) % 2 == 0)
   .Subscribe(x => Console.WriteLine("Even numbers like {0} are cool!", x));

cmd.Where(x => ((int)x) % 2 != 0)
   .Subscribe(x =>
      Console.WriteLine("Odd numbers like {0} are even cooler, especially at {1}!", x.Value, x.Timestamp));

>>> "Even numbers like 2 are cool!"

>>> "Odd numbers like 5 are even cooler, especially at (the current time)!"

Sum it all up, like that guy in Scrubs does all the time

Hopefully that gives you some motivating examples as to why combining the Reactive Extensions with WPF is a really awesome idea, and not just for drag and drop! In the rest of this series I’ll spend some time explaining the rest of the classes and their use, as well as going through a small sample application that I’ve written that I’ll soon be posting.

Written by Paul Betts

June 22nd, 2010 at 1:24 am