Archive for the ‘WPFGlue’ Category

WPFGlue goes WPF 4.0

May 23, 2010 Leave a comment

When VS 2010 was released, I was quite eager to shift to the new version of the framework: the last two releases had brought a lot of real improvements, so I expected the new release to do likewise. Therefore, I upgraded the WPFGlue code to .Net 4.0 and tried it out. These were my experiences:

Upgrade Experience

Upgrading went real smooth: it’s possible to install VS 2010 parallel to VS 2008, so I did that, copied my projects to the new version’s project folder, and opened them. After completing an Upgrade Wizard, there I was… No problem at all, and the Upgrade Wizard didn’t have to change any code, it just set the projects to target the .Net 4.0 Framework instead of .Net 3.5 . (Cool feature: in VS 2010 Express you can select the targeted framework version in the compile options, and you can select older and (hopefully) even newer versions than the one that comes with the VS installation). I have been running VS 2010 and VS 2008 in parallel ever since, and so far haven’t experinced any problems with that.

However, when testing the examples again, there were a few glitches:

  • The LocalizedList in the WPFGlue.Localization namespace caused an error message in the XAML designer.
  • There was a problem with Bindings when navigating backwards through the navigation history in a NavigationWindow.

Error Message in the XAML Designer

The new XAML designer is supposed to be more robust and to be more consistent with the Blend XAML designer. However, one of the tricks I did with the LocalizedList class caused it to hiccup: On this class, I implemented IList so one could set the child elements directly. This was due to the fact that the VS 2008 XAML designer was not handling this very graceful, and I wrote the class before I found out what one has to do to have proper support for typed collections. At the same time, this class can be used as a converter in bindings, in order to translate Enum values into human readable localized strings.

The combination of IList and IValueConverter seemed to be too much for the designer: while the application was compiling and running alright, the designer kept showing squiggly lines about an unset object reference in the XAML pane.

Debugging custom mark-up extensions in VS 2010 Express Edition is a little bit painful. I would recommend to buy the full version if you consider this, and meanwhile I’d recommend to keep away from them… Anyway, I found out that the error message goes away if you don’t implement IList on the same class as IValueConverter, so I just followed the pattern described in the Coding for XAML post.

I posted this problem on the Connect website as product feedback, but they decided to not do anything about it, which I can understand.

TextBox Bindings not Restored when Navigating Backwards

I found this problem first in this thread in the MSDN WPF forum. When you have a page that has data-bound TextBoxes, navigate away from the page and then go back using the Back button of the NavigationWindow that contains the page, the TextBoxes come up blank, even though the DataContext of the page and TextBox is set correctly. It seems that the XAML of the Page is not read the same way when the page is re-displayed; I tried to solve the problem with a custom mark-up extension, and the extension was not instantiated when the page was revisited. So, I tried a DataTemplate instead, and that worked. Finally, I came up with wrapping the page contents into a UserControl. The UserControl seems to read its XAML definition every time it is displayed, and since it inherits the correct DataContext, the problem goes away.

Still, I think this is quite a serious glitch. I posted it to Connect as well, the answer is pending.


Having these strange kinds of errors was a little bit sobering about .Net 4.0. Even so, since I found workarounds, and since the new framework has some cool new features I hope to be using soon, I’m going to stick to it.

So, I updated the downloads page with projects targeting the new version. I’m still keeping copies of the WPF 3.5 version, as well, but I’m not going to include new code into these versions.

Coming Soon…

The next thing I’m planning to do is to research the object lifetime events in WPF 4.0. I was stopped in my tracks a little bit when I found out that the pattern of Loaded and Unloaded events is not quite what one expects (this was still under WPF 3.5), and I’d like to find out what happens there exactly.

Categories: WPFGlue Tags:

WPFGlue Categories

November 7, 2009 Leave a comment

I’d like to classify WPFGlue components according to what they do in the application. So far, the following categories came out:


The WPF navigation framework is just great. Especially the journal: you get the complete forwards and backwards navigation for free, the journal remembers the user input on the page, and this works even when pages are freed in order to save memory.

However, WPF navigation stops just short of being really sticky. Selecting an object on one page and passing it forward to another page is supposed to be done through code behind, and the journal serializes objects instead of hold references to them, which is in itself a wise thing to do in order to not keep these objects from being freed, but makes it difficult to return to the same object instance if one goes back to a page. Also, I don’t like the suggestion in the WPF documentation that the navigation topology should be defined through pages referencing each other through hyperlinks. In my opinion, the pages should work stand-alone as much as possible, and there should be a central definition for the navigation topology, defining the structure of the application and mapping pages to the appropriate places in the object model.

WPFGlue supports navigation through a sticky GoToPage CommandBinding which takes an object parameter and passes it to the DataContext of the new page, a sticky Session property which can hold WeakReferences to business objects while the journal stores pointers to these references, and a ViewModelKit for defining a navigation menu.


The need for localization is immediately obvious for every programmer whose mother tongue is not English. Surprisingly, in WPF localization seems to have been added more or less as an afterthought. While Visual Studio supports localization very nicely for Windows Forms applications, getting at resources contained in satellite assemblies is not straight forward in WPF, and even something as basic as detecting the system language and making it the default culture for display and formatting in the application requires extra work. I could imagine that in the beginning the creators of WPF thought that people would just write different XAML pages for different languages, as is done in HTML, and that the need for localizing XAML only arose after the power of XAML as a programming language became more apparent, and programming elements became more predominant on XAML pages than clear text.

In the Localization category, WPFGlue comes with some sticky MarkupExtensions which make it easier to localize an application. These MarkupExtensions get their values from standard .Net localized resources, so no need for LocBAML or third party tools there. Other MarkupExtensions can be used to set WPF elements’ Language property to the CurrentCulture or CurrentUICulture.


The commanding support in WPF is ingenious. It allows to implement some functionality once and to attach it to all the places where it is applicable, through RoutedCommands and CommandBindings. At the same time, commands decouple the traditional menu and toolbar from the application’s object model, making for great reusable code. Fabulously sticky stuff!

Commands are also the way ViewModels in the MVVM pattern expose their functionality to the user interface. The only unsticky thing about them is that CommandBindings support adding handler routines only through code, either code behind or explicitly. Also, there is no native general way of wrapping a method call into a command.

In the Commanding category, WPFGlue should support mapping commands to method calls, and also direct commands (ICommand implementations that are exposed by a ViewModel) to routed commands which can be handled centrally. There should be a way to set up a CommandSet and to connect it to a page, thus being able to define the available commands and their handlers in a central location. Also, the Commanding category contains a CommandGroup, which executes a series of commands in one go.


MVVM developers seem to avoid the validation features of WPF in favour of validation through the ViewModel or business model, exposed through the IDataErrorInfo interface. I don’t really understand why.

First of all, providing error messages to a user is not the job of a business object. The business object shouldn’t know whether it is used by an interactive user, a background service, or a batch job. In addition to that, in order to be able to provide meaningful error messages, the business object model would have to localize its error messages, and I wouldn’t want to burden my business objects with a job like that.

Second, while the business model knows what itself can do, it has no idea about what the developer of an application that reuses it may want to do. It would be perfectly justified to forbid certain legal property values because they are outside the scope of the current application. In this case, the ViewModel would have to constrain the values it allows for a certain property before it passes them on to the business object model.

So why not let the ViewModel do the job? I agree, the ViewModel is responsible. However, I wouldn’t use IDataErrorInfo, because that forces me to re-implement a lot of functionality that is already present in the WPF validation model. For example, resetting the values of an object to their pre-edit state before they are committed while still being able to provide instant validation feedback is really easy with ValidationRules and a BindingGroup, but requires a lot of effort, including ongoing maintenance effort, when done in a ViewModel specialized for a certain business model.

So, what I’d do instead is create a ViewModelKit that allows one to define a group of ValidationRules, which may or may not be dependent on validation functions in the business object model, and to allow setting these ValidationRules to a BindingGroup using a sticky property.

In addition to that, one would find workarounds for some minor problems with Validation.ErrorTemplate and ways to inform the ViewModel of validation results in the Validation category of WPFGlue.

Application Services

Application services would be things like forwarding application lifetime events to the ViewModel or providing services that are available in the operating system environment without creating a dependency from the ViewModel to the View.

Examples for this are a MessageBox that is invoked through sticky properties, a sticky StartupCommand property, a markup extension that allows to include application settings in the user interface, or context sensitive help through sticky properties.

Common Tasks

Common tasks would be jobs that recur in user interfaces, so that it makes sense to implement them in sticky ViewModels.

Examples would be a FileManager that provides support for the usual File menu commands for any type of document, a ListEditor that has commands for moving, adding and deleting items in collections implementing the standard collection interfaces, a ListPager that divides a collection into pages of a given length, and the like.


This is only a tentative list. The only category that will definitely survive is Common Tasks, since the others hopefully will be replaced by native support through WPF as the framework develops and the gaps between business object model and user interface vanish, so that there is no more need to fill them with glue.

Suppose You Have a Business Object Model…

November 5, 2009 Leave a comment

which can do everything you want to do with the application. So what would be the job of the UI?

The UI enables a user to interact with the model. In terms of the business model this corresponds to

  • instantiating objects or
  • finding objects that have been instantiated already,
  • accessing their properties and
  • calling their methods.

If it is the UI’s job to forward these functions to the user, it has to be able to do the following:

  • instantiate objects,
  • provide means to navigate their relationships,
  • provide means to modify their relationships,
  • keep track of object selections,
  • display and edit object’s properties,
  • provide means to call methods,
  • capture and display the result of method calls.

“Provide means” in this context means to provide a visual presentation for the action and to translate input gestures into the necessary method calls on the object model.

In addition to that, there are some tasks that mainly concern the UI, not the object model:

  • provide descriptions of itself (internationalized),
  • provide context sensitive online help,
  • translate user readable values into machine readable values and vice versa,
  • provide validation feedback.

Ok, so much for the cooperation between business model and UI layer. However, there are some services that every application needs, independent from the actual business object model. These services include

  • persistence of business objects,
  • Notifying the business model of application lifetime events, i.e. startup and shutdown,
  • persistence of application settings.

All of these functions are already present in .Net. Most of them are also available in WPF. It remains to be seen how to connect the two in the cases where the connection is not obvious.

WPFGlue Patterns

November 5, 2009 4 comments

Let’s recapitulate the design requirements for WPFGlue components:

  • You shall not duplicate functionality that is already in the WPF framework.
  • You shall not mess with WPF’s correct function, like keeping objects from being freed and the like evil practices.
  • You shall not require code behind.
  • You shall not demand sub-classing controls.
  • You shall not demand interface implementations from your business objects (unless the interfaces are part of WPF itself), nor common base classes, nor any other construct that commits the developer to a strong coupling between your glue and his code.

The following design patterns have proved suitable for development under these constraints:

Sticky Properties (a.k.a. Attached Properties)

Attached properties can be used to extend the state of any element in WPF. They can be used in XAML, and neither the framework-supplied controls nor the business object model need to know them. So, they are suitable for WPFGlue.

Built-in examples for attached properties are the Canvas.Left and Canvas.Top properties, which the WPF Canvas uses to store the positions of its child elements.

Sticky Behaviours (a.k.a. Attached Behaviours)

Attached behaviours are a special kind of attached properties that register event handlers on the elements they are attached to. The event handlers provide additional functionality to the elements which is triggered through the elements standard events, while the implementation of the event handlers is contained in the class that defines the attached property.

A built-in example for a sticky behaviour is the SpellCheck.IsEnabled property, which adds the functionality of spell checking to controls based on TextBoxBase.

Josh Smith writes about attached behaviours in this article; Attached behaviours are introduced and defined by Nikhil Kothari here.

Sticky CommandBindings

Work like sticky behaviours, with the difference that they don’t handle events, but standard routed commands. Attaching a sticky CommandBinding to a WPF FrameworkElement means that this element will be able to handle the command, without having to change the original implementation of the element. A sticky CommandBinding should add / remove the CommandBindings when the value of an attached property changes.

Pete O’Hanlon gives an almost perfect example of this pattern here. Almost perfect because he uses a class CommandBinding instead of the CommandBindings collection, but this might be justified on his case since he expects the command to be used by many elements per page.

Sticky ViewModels (a.k.a. Mini-ViewModels)

Sticky ViewModels are ViewModels that don’t wrap a business object, but attach themselves to it and expose a specialized, reusable bit of functionality through their own properties and commands. Typically, a sticky ViewModel wouldn’t be the DataContext of a FrameworkElement, but it would be attached to the element as a sticky property and use the FrameworkElement’s DataContext to find the model it is supposed to work on. Controls inside the scope of the FrameworkElement would then bind to properties of the sticky ViewModel in order to benefit from it.

Quite often jobs like this are done through converters (Converters are classes that implement the IValueConverter interface). However, I view this as converter abuse. A converter is not intended for anything but type conversions, translating data between different data types and string presentations. If the intention of the solution is rather to achieve some more complex interaction between the View and the Model, I’d recommend a sticky ViewModel instead. Usually these cases are discovered by feeling the need to pass more information into the conversion routines than is readily available…

While Mini-ViewModel seems to imply that the functionality of such a class would normally be quite limited, I could imagine whole page ViewModels using this technique.

Colin Eberhardt describes the Mini-ViewModel pattern here and gives a nice example.


A ViewModelKit would be a class or set of related classes that can be instantiated and configured as XAML resources, and then be used as ViewModels through referencing the resource.

A built-in example for a ViewModelKit would be the CollectionViewSource class, which can be used to configure views of business object collections.

Sticky Markup (a.k.a. Custom Markup Extensions)

Custom markup extensions are classes derived from System.Windows.Markup.MarkupExtension, which can be used in XAML attributes using the markup extension syntax, like {Binding value}. Writing custom markup extensions is not documented very well in the WPF documentation, and I use them sparingly. They need to be initialized in place, i.e. where they are used in XAML. This limits their “stickiness” to situations where the information they need to do their job is either very simple or can be discovered from the built-in application framework. For example, I found them useful for accessing localized resources, application settings, or the current UI language.

The Sticky Base of WPFGlue

November 5, 2009 Leave a comment


when I first learned about WPF (short for Windows Presentation Foundation, the current UI framework for Microsoft .Net technology) I was fascinated by the idea that one could simply take a business object model, provide some forms written in XAML, connect the two through data binding, and have a new application… Unfortunately, I soon realized that there is still a lot of work to do until one reaches this stage. There are always areas where the relationship between what happens in the UI and what should go on in the business objects is not straight forward, or where the final step connecting business model and UI is missing.

The usual answer to this is ViewModels. In the Model-View-ViewModel pattern, which is the trend in WPF development at the moment, the gap between model and view is filled by the ViewModel, a specialized adapter class that knows the business model and presents it in a way that defines the functionality of the application and is tailored to fit into the data binding system of WPF. However, the examples I have studied so far did not convince me. While being very ingenious and most instructive for understanding the MVVM pattern, and doing a real good job in what they want to achieve, I found two points of criticism about these examples:

  • The ViewModels created are specialized. They may be made of reusable parts, but using them just creates another type of glue code, like forwarding the values of properties, or wrapping method calls into commands.
  • The ViewModels tend to duplicate or bypass functionality that is already provided by the WPF framework itself, like validation or navigation, because it is not easily accessible through the means the self-imposed constraints of the correctly implemented MVVM pattern leave available.

This is when I had the idea of WPFGlue. I’d like to have a library of small ViewModel building blocks which can be used from XAML files, much in the way non-visual components can be integrated into Windows Forms applications. Ideally, one could take one’s business model, and apart from that wouldn’t need to write any code except XAML in order to create an application. In order to achieve that, the components of the WPFGlue library should be small, independent of each other except where they establish their prerequisites themselves, and put no requirements on the Views on the one hand and on the business objects on the other.

So, the sticky base of WPFGlue is:

  • You shall not duplicate functionality that is already in the WPF framework.
  • You shall not mess with WPF’s correct function, like keeping objects from being freed and the like evil practices.
  • You shall not require code behind.
  • You shall not demand sub-classing controls.
  • You shall not demand interface implementations from your business objects (unless the interfaces are part of WPF itself), nor common base classes, nor any other construct that commits the developer to a strong coupling between your glue and his code.

By the way…

There are people out there who have created great frameworks for writing applications in WPF with MVVM. I think mine is (err, will be) different, but probably not better. If you are interested in the topic, check out these links:

WPF: If Heineken did MVVM Frameworks Part 1 of n by Sacha Barber on CodeProject

Caliburn by Rob Eisenberg and Co.

MVVM Foundation Classes by Josh Smith

Categories: WPFGlue Tags: ,