<ListView ItemsSource="{Binding Instances}" />

For some strange reason all the mouse events seem to be directly routed instead of bubbling like other input events. Only some magic of the framework causes them to be raised for every hit control. This causes the sender to be totally worthless, since it is always the “current” object.

Uncle Google just brought up a useless and wrong answer on the “site with a hyphen.” But after some fiddling I found the answer: just use an EventSetter to set the handler on all items:

<ListView ItemsSource="{Binding Instances}" >
    <ListView.Resources>
        <Style TargetType="ListViewItem">
            <EventSetter Event="MouseDoubleClick"
                Handler="OnDoubleClick" />
        </Style>
    </ListView.Resources>
</ListView>

Then I wanted to post the question and answer to stackoverflow so others can profit from it too. It turns out that this is an already solved problem: WPF ListView: Attaching a double-click (on an item) event. Furthermore, both this page and the linked thread on the MSDN Forum were also available on the google results. Meh.

The basic structure is three-fold: the Model where the actual data resides, the View which interacts with the user and the View Model as a intermediate layer. I will start out with describing the View, which is really thin. Afterwards I’ll talk a bit why the Model alone is not enough. In the last part I’ll describe my approach to filling the gap.

The View

The easiest part is the View. In WPF, this is the easiest part:

<Window ... DataContext="{StaticResource unitOfWork}">
  <ContentPresenter
    Content="{Binding}"
    ContentTemplateSelector="{StaticResource defaultTemplateSelector}" />
</Window>

The unitOfWork is the root object of the current View Model tree and the defaultTemplateSelector uses meta data to map from a View Model class to the appropriate WPF template. In my case, this is coming from the bowels of the database but you can also just graft XAML (directly or by reference) onto the View Model.

Everything else in the View is done by binding to parts of the View Model and choosing the right template, either by way of the default template selector or overriding it when a special context arises (e.g. list item vs. detail view).

The Model

The most basic component is the Business Layer or the Model. This layer may talk to the database, call out to services, or do whatever else is needed to implement its interface.

There are many reasons why WPF cannot directly bind to this layer:

• Not built for binding. No INotifyPropertyChanged or INotifyCollectionChanged interfaces.
• May block. Talking to the network or the hard disk may introduce delays which are unacceptable for the UI.
• Doesn’t know about multi-threading. Usually Models know only about Transactions, which are by themselves inherently single-threaded.
• No place for the View’s state. Where should the View store things like window sizes, selected items or other ephemeral information?

None of these points is relevant when doing batch processing or when doing an ASP.NET site, which is a good benchmark for me that the Model shouldn’t burden itself with trying to solve them.

The View Model

To work around the “shortcomings” of the Model, this additional layer provides mechanisms to decouple user interaction from delays in the Model and a place to add additional properties to store and share View state between multiple Views.

The basis of all presentable Models is this abstract base class:

public abstract class PresentableModel
  : INotifyPropertyChanged
{
  public ModelFactory Factory { get { return AppContext.Factory; } }
  protected IContext DataContext { get; private set; }
  protected IThreadManager UI { get { return AppContext.UiThread; } }
  protected IThreadManager Async { get { return AppContext.AsyncThread; } }

  public PresentableModel(IContext dataCtx) {
    UI.Verify();
    DataContext = dataCtx;
  }

  #region Public interface

  private ModelState _State = ModelState.Loading;
  public ModelState State {
    get {
      UI.Verify();
      return _State;
    }
    protected set {
      UI.Verify();
      if (value != _State) {
        _State = value;
        OnPropertyChanged("State");
      }
    }
  }

  #endregion

  #region INotifyPropertyChanged Members

  private event PropertyChangedEventHandler _PropertyChangedEvent;
  public event PropertyChangedEventHandler PropertyChanged {
    add {
      UI.Verify();
      _PropertyChangedEvent += value;
    }
    remove {
      UI.Verify();
      _PropertyChangedEvent -= value;
    }
  }

  protected virtual void OnPropertyChanged(string propertyName) {
    UI.Verify();
    if (_PropertyChangedEvent != null)
      _PropertyChangedEvent(this, new PropertyChangedEventArgs(propertyName));
  }

  protected void AsyncOnPropertyChanged(string propertyName) {
    Async.Verify();
    UI.Queue(UI, () => OnPropertyChanged(propertyName));
  }

  #endregion

}

• IThreadManager: a component that can Verify() whether execution is on the right thread and Queue() an action to the managed thread. Each model has two of them. The UI manager takes care of the UI thread and the Async manager handles asynchronous actions. The default implementations use the Dispatcher and the ThreadPool respectively.
• State: a flag to indicate in which state the PresentableModel is. Possible states include Invalid, Loading, and Active. This also shows the default pattern for a Property on a PresentableModel: It can only be accessed from the UI thread (lines 19 and 23) and only notifies on real changes (line 24 and 26).
• AsyncOnPropertyChanged(): the only method on PresentableModel that may be called from a background thread (line 54). By convention the method name starts with “Async”. The easiest of tasks, calling OnPropertyChanged() on the UI thread, is handled by using UI.Queue().

Actual Presentables

As an easy example of the flexibility of this model, I present you a SearchActionModel which can react on updates to the search term and to asynchronously batch queries to the database whose results are displayed incrementally.

public class SearchActionModel: PresentableModel
{
  private string _searchTerm = null;
  public string SearchTerm {
    get {
      UI.Verify();
      return _searchTerm;
    }
    set {
      UI.Verify();
      if (_searchTerm != value) {
        _searchTerm = value;
        OnNotifyPropertyChanged("SearchTerm");
        Async.Queue(DataContext, AsyncUpdateResults);
      }
    }

  private ObservableCollection<SearchResult> _results = new ObservableCollection<SearchResult>();
  private ReadOnlyObservableCollection<SearchResult> _resultsProxy = new ReadOnlyObservableCollection<SearchResult>(_results);
  public ReadOnlyObservableCollection<SearchResult> Results {
    get {
      UI.Verify();
      return _resultsProxy;
    }
  }

  private void AsyncUpdateResults() {
    Async.Verify();
    UI.Queue(UI, () => {
      _results.Clear();
      State = ModelState.Loading;
      string searchTerm = _searchTerm;
      Async.Queue(DataContext, () => {
        var results = DataContext.GetQuery<SearchResult>().Where(r => r.Name.Contains(searchTerm));
        foreach(var r in results) {
          UI.Queue(UI, () => _results.Add(r));
        }
        UI.Queue(UI, () => State = ModelState.Active);
      });
    });
  }
}

Note how the multiple Queue() operations are nested to enforce an implicit and lock-less sequencing of the various actions.

The View is quite primitive:

<UserControl x:Class="App.View.SearchActionView" ...>
  <DockPanel>
    <TextBox
      Text="{Binding SearchTerm}"
      DockPanel.Dock="Top" />
    <ctrls:LoadingDindicator DockPanel.Dock="Top" />
    <ListBox
      ItemsSource="{Binding Results}" />
  </StackPanel>
</UserControl>

Note: the LoadingIndicator is a small widget binding to the State Property and displaying a little spinning wheel when the Model is not Active.

Of course even this trivial example is not without its share of problems:

• The Results collection is cleared on every input (line 30). A more sophisticated implementation might want to filter the results locally before going to the database again. Linq should make it easy to encapsulate the filter logic.
• The loading code depends on a streaming Linq provider (line 35). If the underlying Linq provider blocks too long before returning the first result, a local workaround might be to implement client side paging and make multiple queries which only fetch a few elements each.
• All Queue() magic aside, the code does play with fire and there are several possibilities to breach thread safety. For example, the search term has to be copied on the UI thread into a local variable (line 32) to avoid accessing the SearchTerm property from the background thread (line 34).

Conclusion and Future Work

This organisation of threading and binding is a powerful way to get highly flexible and easily bindable model classes for use with WPF. Still programming in a free threading application is playing with fire and even slight missteps may produce subtle and hard to find bugs.

Other things are more of a nuisance because I didn’t come around implementing them yet. First, the State should support ref-counting semantics, because currently multiple parallel updates lead to the model being Active as soon as the first update finishes. The other things are related to the IThreadManager. It is currently impossible to abort actions once they’ve been queued and actions are mostly processed in FIFO which is annoying if somewhere is a longer running action, perhaps even consisting of multiple enqueued parts, which delay the reaction to the user’s last input.

Wrong:

<Application.Resources>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary Source="TextStyle.xaml" />
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
    <!-- other styles can appear in the resource dictionary too -->
    <Style TargetType="{x:Type Button}"
           x:Key="ButtonStyle">
        <Setter Property="Background"
                Value="#feca00" />
    </Style>
</Application.Resources>

Right:

<Application.Resources>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary Source="TextStyle.xaml" />
        </ResourceDictionary.MergedDictionaries>
        <!-- other styles can appear in the resource dictionary too -->
        <Style TargetType="{x:Type Button}"
               x:Key="ButtonStyle">
            <Setter Property="Background"
                    Value="#feca00" />
        </Style>
    </ResourceDictionary>
</Application.Resources>

Note the difference in where the additional <Style>s go.

The ViewModel

The ViewModel acts as an Adapter between the View and the Model. A very intelligent Adapter. It contains all logic, properties and events to allow a “trivial” View implementation. This provides for a clear separation of concerns:

• the Model as data store
• the View as vehicle for actual user interaction, that is drawing pixels and receiving input events
• the ViewModel to transform the data into view-specific structures, translate manipulation of these structures back into the Model and hold view-specific state

Example

A simple example for a ViewModel (or Presenter Model, as it called in the Composite Application Guidance for WPF) is the CollectionView used as Adapter between the ListBox and a collection.

You can think of a collection view as a layer on top of a binding source collection that allows you to navigate and display the collection based on sort, filter, and group queries, all without having to manipulate the underlying source collection itself. If the source collection implements the INotifyCollectionChanged interface, the changes that raise the CollectionChanged event are propagated to the views.

Benefits

One of the nice effects of a ViewModel is the ability to share such a model, giving instant synchronisation between multiple Views. This works because the individual Views do not have any state, but are completely dependent on the ViewModel.

Another subtle but nice point is the massive reduction in imposed structure on the View. Only a single, light-weight injection interface is needed to give the View access to the ViewModel. This allows more flexibility in evolving the ViewModel, since only breaking changes affect all Views. On the other hand, Views can incrementally support more and more features of a given ViewModel without having to pay big up-front costs in implementing/stubbing a huge interface. In the same vein, the ViewModel has no dependency of the View in any kind, which makes the ViewModel the ultimate lookless control.

Automated testing became a big topic over the last years and the ViewModel follows the trend by being very easy to test. To test a presenter/controller in a MVP or MVC architecture, both the View and the Model have to be replaced for a test. Since a View of a ViewModel shouldn’t contain any “real” code, testing can concentrate on the functionality of the ViewModel and only mock up the Model, something which is needed for most tests of components using the Model anyways.

Last (but perhaps not least) is a purely aesthetic point: All dependencies in a ViewModel architecture point in the same direction. The Model works with a data source, the Business Logic works with the Model, the ViewModel works with the Business Logic and the Model, and the View only works with the ViewModel. This enables the uniform re-use of the same mechanisms and patterns — Validation, Transactions, Change Notification, etc — over the various levels of the application.

Conclusion

ViewModels represent the current top of the evolution in lookless controls. By combining data binding and the programmatic power of a Presenter/Controller component into a single concept without dependencies on a specific View technology, they provide a high degree of flexibility in representing the internal state of an application without getting bogged down in the intricate details of designing a great user experience.

I’m already thrilled how this will work out in more complex scenarios. And what’ll come next

From Brandon Cannaday at Switch on the code.

I use this Style to surround each TabItem Content with a ScrollViewer:

        <Style TargetType="{x:Type TabControl}">
            <Setter Property="Template">
                <Setter.Value>
                    <ControlTemplate TargetType="{x:Type TabControl}">
                        <Grid>
                            <Grid.RowDefinitions>
                                <RowDefinition Height="Auto"/>
                                <RowDefinition Height="*"/>
                            </Grid.RowDefinitions>
                            <TabPanel Grid.Row="0" IsItemsHost="True" />
                            <ScrollViewer Grid.Row="1"
                                VerticalScrollBarVisibility="Auto"
                                Margin="5,5,5,5"
                                Background="White">
                                <ContentPresenter ContentSource="SelectedContent" />
                            </ScrollViewer>
                        </Grid>
                    </ControlTemplate>
                </Setter.Value>
            </Setter>
        </Style>

Soil.NET is a port of an old DOS application written in Pascal to the .NET framework. It is a one-off programming project for the civil engineering office Steinhauser, who are useing the application to support writing expertises in the area of vibration protection and seismology. While the mathematical core could be taken almost literally, the use of a modern GUI toolkit WPF enabled important improvements in user interface experience:

• Free data entry: the DOS application only allowed sequential input. The WPF implementation not only enables free entry and correcting of parameters, but also displays the results immediately to the user. The feedback allows users to test more combinations of parameters in the same time.
• Model comparisons: as with data entry, models could only be input sequentially. Single typos thus lead to having re-type the whole dataset. The new implementation allows models to be input independently and to choose, display, and print different charts and combinations without having to re-enter any data.
• Graphical quality: the DOS application was restricted to 640×480 pixels on screen and when printing. Of course this doesn’t meet current expectations and is noted negatively when including the graphics in expertises and similar documents. Trhough using the ZedGraph library, graphics can be created in arbitrary resolutions and print outs conform to the specifications of the printer and the used paper formats.

Finally a printed page and a screenshot of the complete application:

This sucks: “clr-namespace:My.Sub; assembly=MyAssembly”

This works: “clr-namespace:My.Sub;assembly=MyAssembly”

See the difference? Unbelievable, but there is just a space between the ‘;’ and “assembly”. Sure, it’s not possible to use Trim() during parsing. Or there is another reason I dont know why.

• Whiteboard
• Finger Tracking
• Head Tracking

http://johnnylee.net/projects/wii/

COOOOLLLLL!!!!

And for all WPF Friends:

http://www.cynergysystems.com/blogs/page/rickbarraza?entry=connecting_to_the_wii_control

Abstract: While there are a few demo videos how to create nice buttons with Expression Blend, I didn’t find a straight-forward description how to do a nice button from a image. This article tries to fill this gap and a bit more. The IconButtonStyle takes the contents of the button, decorates them with a little shadow and when the user presses the butten, it generates a subtle animation “pushing” the content into the screen.

Today I looked at it again and…
thought I should be able to create a custom System.Windows.Media.ImageSource using a hidden BitmapSource for XAML usage. Far from it! While ImageSource is public abstract, it uses some “private parts” from Windows.Media.Composition.DUCE which are not available to the common folk.

Finally uncle google came to the rescue: in a microsoft forum posting (“Using Bitmap resources from .resx file in WPF“) Ashish Shetty explains how to use a special URI syntax to access resources directly from XAML. The catch is that the images have to be built as “Resource” and not as “Embedded Resource“. This seems to be only available if the assembly was created from one of the WPF project templates[1]. But if everything is done right, the resource can be accessed by simply setting the “Source” property:

<!-- local assembly -->
<Image Source="/directory/foo.png" />
<!-- referenced assembly -->
<Image Source="/AssemblyName;component/directory/foo.png" />

More details can be found in the MSDN article “Windows Presentation Foundation Application Resource, Content, and Data Files“.

[1] See the last comment at How to use resources (images) in dll assembly?