Author: David Rickard

Since ReactiveUI’s ReactiveList<T> has recently been deprecated, I’ve been moving to DynamicData.

One feature I used from ReactiveList was item change tracking. It might look something like this:

var myList = new ReactiveList<MyClass>();
myList.ChangeTrackingEnabled = true;
myList.ItemChanged
	.Where(x => x.PropertyName == nameof(MyClass.SomeProperty))
	.Select(x => x.Sender)
	.Subscribe(myObject =>
	{
		// Do some stuff
	});

In DynamicData it goes like this:

var myList = new SourceList<MyClass>();
myList
	.Connect()
	.WhenPropertyChanged(myObject => myObject.SomeProperty)
	.Subscribe(propValue =>
	{
		MyClass myObject = propValue.Sender;
		string newValue = propValue.Value;
		// Do some stuff
	});

There is also WhenValueChanged, which just gives you the new property value as a straight IObservable:

myList
	.Connect()
	.WhenValueChanged(myObject => myObject.SomeProperty)
	.Subscribe(newValue =>
	{
		// Do some stuff
	});

The most powerful is WhenAnyPropertyChanged, which can tell you when any of the properties changed:

var myList = new SourceList<MyClass>();
myList
	.Connect()
	.WhenAnyPropertyChanged()
	.Subscribe(myObject =>
	{
		// Do stuff with myObject
	});

Or when any set of specified properties has changed:

var myList = new SourceList<MyClass>();
myList
	.Connect()
	.WhenAnyPropertyChanged(nameof(MyClass.FirstProperty), nameof(MyClass.SecondProperty))
	.Subscribe(myObject =>
	{
		// Do stuff with myObject
	});

My project is MVVM and I had been using ReactiveList<T> as my go-to observable collection for viewmodel properties. But ReactiveUI deprecated ReactiveList in 8.6.1. So I needed to get on to the new recommended library: DynamicData.

But there is no direct drop-in replacement you can do like ObservableCollection<T> <-> ReactiveList<T>. I grabbed the NuGet package, dropped in SourceList<T>, but that doesn’t work. SourceList<T> does not implement INotifyCollectionChanged, which is what WPF looks for when binding to ListView, GridView, ItemsControl, etc. So how do we bind to this thing? After some fruitless searches I dug through the source code unit tests and found the answer. Add this to the viewmodel class:

private readonly SourceList<string> myList = new SourceList<string>();
public IObservableCollection<string> MyListBindable { get; } = new ObservableCollectionExtended<string>();

And this to its constructor:

this.myList.Connect().Bind(this.MyListBindable).Subscribe();

It’s a two-stage affair. The SourceList<T> is where all the operations happen. Adds, clears, deletes and all that. But you don’t directly observe the source list. To do that, you need to call Connect() to get an IObservable<IChangeSet<T>> . If you follow this observable you can see everything that’s changed about the collection by looking at the change sets.

But you still need to do one more thing: get it in a format that the WPF UI can bind to, that is an object that implements INotifyCollectionChanged. ObservableCollectionExtended is DynamicData’s implementation of that. The Bind() call “slaves” it to the SourceList. Any changes made in the SourceList are now reflected in the ObservableCollectionExtended. A final call to Subscribe() activates it. Now since we’re exposing it as a property, we can bind our UI to it:

<ItemsControl
	ItemsSource="{Binding MyListBindable}"
	...

The important thing here is to remember that this property is here ONLY so the UI can bind to it. That’s why I’ve named it Bindable: so I’ll realize I’m doing something wrong if I try to modify it directly.

The ObservableCollectionExtended property also allows you to get batches to avoid update churn from making individual edits to the collection. When you call Edit() on the SourceList<T>:

this.myList.Edit(innerList =>
{
	innerList.Clear();
	foreach (string name in names)
	{
		innerList.Add(name);
	}
});

It will batch up all the changes made into one event under INotifyCollectionChanged, meaning the UI only needs to react once.

When writing an MVVM application, you want to separate from the UI. However you also need to make sure that UI updates happen on the UI thread. Changes made through INotifyPropertyChanged get automatically marshaled to the UI thread, so in most cases you’ll be fine. However, when using INotifyCollectionChanged (such as with an ObservableCollection), these changes are not marshaled to the UI thread.

This means that unless you modify your collection on the UI thread, you’ll get a cross threading error. Thus the problem. We’re in the ViewModel and we don’t have access to the Dispatcher. That’s on a View object. How do we update the collection on the UI thread?

I came up with a small static class to help with this:

public static class DispatchService
{
    public static void Invoke(Action action)
    {
        Dispatcher dispatchObject = Application.Current.Dispatcher;
        if (dispatchObject == null || dispatchObject.CheckAccess())
	{
            action();
        }
        else
        {
            dispatchObject.Invoke(action);
        }
    }
}

When your ViewModel gives the DispatchService actions, it can run them on the correct thread. Which is, in the case of unit tests, always the current thread. A call to the DispatchService may look like this:

DispatchService.Invoke(() =>
{
    this.MyCollection.Add("new value");
});

The use of a simple lambda statement makes it a relatively lightweight way of updating on the correct thread.

A common user interface tweak is to save the size and location of a window and restore that state when the program starts up again. That way, the users don’t need to re-do their work of resizing and moving the windows to where they want them. However I’ve found that there isn’t really a convenient way to do with in C#. Many solutions focus on recording the window width, height, x and y coordinates and current state (maximized, restored, etc), then applying all those values again on startup. But then you have to deal with edge cases: What if the user has changed resolutions since your program last ran? What if it was present on a monitor that’s now disconnected?

Fortunately, there are a couple of native Windows functions that can do all this work for us: SetWindowPlacement and GetWindowPlacement. MSDN has a sample demonstrating how to PInvoke to these functions in a WPF project, but it’s got a few issues with it. For one, it’s trying to store the placement as a custom type in settings, which can cause strange errors every time you open your Settings file. Here’s my take on it:

using System;
using System.IO;
using System.Runtime.InteropServices;
using System.Text;
using System.Xml;
using System.Xml.Serialization;

namespace WindowPlacementExample
{
    // RECT structure required by WINDOWPLACEMENT structure
    [Serializable]
    [StructLayout(LayoutKind.Sequential)]
    public struct RECT
    {
        public int Left;
        public int Top;
        public int Right;
        public int Bottom;

        public RECT(int left, int top, int right, int bottom)
        {
            this.Left = left;
            this.Top = top;
            this.Right = right;
            this.Bottom = bottom;
        }
    }

    // POINT structure required by WINDOWPLACEMENT structure
    [Serializable]
    [StructLayout(LayoutKind.Sequential)]
    public struct POINT
    {
        public int X;
        public int Y;

        public POINT(int x, int y)
        {
            this.X = x;
            this.Y = y;
        }
    }

    // WINDOWPLACEMENT stores the position, size, and state of a window
    [Serializable]
    [StructLayout(LayoutKind.Sequential)]
    public struct WINDOWPLACEMENT
    {
        public int length;
        public int flags;
        public int showCmd;
        public POINT minPosition;
        public POINT maxPosition;
        public RECT normalPosition;
    }

    public static class WindowPlacement
    {
        private static Encoding encoding = new UTF8Encoding();
        private static XmlSerializer serializer = new XmlSerializer(typeof(WINDOWPLACEMENT));

        [DllImport("user32.dll")]
        private static extern bool SetWindowPlacement(IntPtr hWnd, [In] ref WINDOWPLACEMENT lpwndpl);

        [DllImport("user32.dll")]
        private static extern bool GetWindowPlacement(IntPtr hWnd, out WINDOWPLACEMENT lpwndpl);

        private const int SW_SHOWNORMAL = 1;
        private const int SW_SHOWMINIMIZED = 2;

        public static void SetPlacement(IntPtr windowHandle, string placementXml)
        {
            if (string.IsNullOrEmpty(placementXml))
            {
                return;
            }

            WINDOWPLACEMENT placement;
            byte[] xmlBytes = encoding.GetBytes(placementXml);

            try
            {
                using (MemoryStream memoryStream = new MemoryStream(xmlBytes))
                {
                    placement = (WINDOWPLACEMENT)serializer.Deserialize(memoryStream);
                }

                placement.length = Marshal.SizeOf(typeof(WINDOWPLACEMENT));
                placement.flags = 0;
                placement.showCmd = (placement.showCmd == SW_SHOWMINIMIZED ? SW_SHOWNORMAL : placement.showCmd);
                SetWindowPlacement(windowHandle, ref placement);
            }
            catch (InvalidOperationException)
            {
                // Parsing placement XML failed. Fail silently.
            }
        }

        public static string GetPlacement(IntPtr windowHandle)
        {
            WINDOWPLACEMENT placement = new WINDOWPLACEMENT();
            GetWindowPlacement(windowHandle, out placement);

            using (MemoryStream memoryStream = new MemoryStream())
            {
                using (XmlTextWriter xmlTextWriter = new XmlTextWriter(memoryStream, Encoding.UTF8))
                {
                    serializer.Serialize(xmlTextWriter, placement);
                    byte[] xmlBytes = memoryStream.ToArray();
                    return encoding.GetString(xmlBytes);
                }
            }
        }
    }
}

To get the placement of an existing window, you give it the native handle for the window, and get back a string of XML that represents the placement for the window. You save this string somewhere, then when the program starts back up again, apply it with SetPlacement. The above code works for both WinForms and WPF. And in both cases you can open your Properties/Settings.settings file and add a new setting to store the string:

This will store the window state locally, per-user. Of course you could also store the string wherever you wanted to.

What I like about this approach is that the WindowPlacement class does the XML serialization for you and gives you a nice, tidy string containing all the placement data.

But where in the program code should we hook in to save and re-apply the window placements? The answer is a bit different between WinForms and WPF.

WPF:

You might benefit by throwing a couple of extension methods on the WindowPlacement class to make things a bit easier:

public static void SetPlacement(this Window window, string placementXml)
{
    WindowPlacement.SetPlacement(new WindowInteropHelper(window).Handle, placementXml);
}

public static string GetPlacement(this Window window)
{
    return WindowPlacement.GetPlacement(new WindowInteropHelper(window).Handle);
}

To save the window placement, just handle the Closing event on the Window:

private void Window_Closing(object sender, CancelEventArgs e)
{
    Settings.Default.MainWindowPlacement = this.GetPlacement();
    Settings.Default.Save();
}

To restore, you’ll need to hook in on SourceInitialized:

protected override void OnSourceInitialized(EventArgs e)
{
    base.OnSourceInitialized(e);
    this.SetPlacement(Settings.Default.MainWindowPlacement);
}

WinForms:

This one is a bit more straightforward. Save on the FormClosing event and restore the window state in the Load event handler. The Form’s native handle is accessible from its Handle property.

Now we have a robust and relatively painless way of persisting window sizes and positions, and we only need to keep track of one string per window.