Thread Dispatcher

WPF has the concept of a DispatcherObject underpinning every UI object. The Dispatcher's task is to marshall operations from all threads onto the DispatcherObject's owner thread. This is needed because Windows UI programming is not thread safe.

I have run into multi-threading problems with certain libraries which had thread affinity requirements. WPF's Dispatcher pattern appealed to me and I wanted to have an attempt at writing my own simple implementation. Sample usage:

var td = new ThreadDispatcher();
td.Invoke(() => someObject.Action());
var result = td.Invoke(() => someObject.ShouldQuit());
if(result == true)
    td.Stop();

The code for the ThreadDispatcher is here: ThreadDispatcher.cs

The next step was to cater for (hypothetical) situations where I had lots of non-thread-safe objects. These objects would need to be always accessed on the same thread, but there was no requirement for each object to have a unique thread. I created a ThreadDispatcherPool implementation based on .net's ThreadPool. The use it, you just request a ThreadDispatcher from the ThreadPool when you create a new Non-thread-safe object:

ThreadDispatcherPool.GetThreadDispatcher();

The code for ThreadDispatcherPool is here: ThreadDispatcherPool.cs

(A potential problem with the ThreadDispatcherPool is that a client could call Stop() on a shared ThreadDispatcher...)

Buffered Binding

WPF Bindings support three different update triggers:

• PropertyChanged: Updates the binding source immediately whenever the binding target property changes.



• LostFocus: Updates the binding source whenever the binding target element loses focus.



• Explicit: Updates the binding source only when you call the UpdateSource method.

In my last application I found LostFocus and PropertyChanged to be inadequate for my requirements. PropertyChanged would trigger some costly validation operations on every key stroke (overkill), while PropertyChanged would require the user to "click out" of the input area to activate validation. On single input forms this made for a very confusing user interface.

The solution in WPF for this is to use the Explicit UpdateSourceTrigger and then make informed decisions about when to update the source binding. For my purposes, I found the best experience was achieved by triggering a SourceUpdate only when the user stops typing for some period of time (I picked 1.5 seconds). Writing this code for every input field did not appeal to me, so I wrote an attached behaviour to handle this. I also found the syntax of the attached behaviour ugly, so I wrote a markup extension to automate the creation of the attached behaviour. The final syntax would look like this:

<TextBox Text="{Util:BufferedBinding {Binding Name, ValidatesOnDataErrors=True}}"/>

I call this the BufferedBinding and the code is available below.

BufferedBinding.cs

First Post

Testing code formatting. 

for(int i = 0; i< 10; i++)