Validating Objects with ValidationRules
In examples about writing WPF applications with the MVVM pattern, normally one doesn’t find any reference to ValidationRules. The normal way to do things there is to wrap the business object into the ViewModel and to implement IDataErrorInfo on the ViewModel. However, there are several points about this approach which I don’t like:
- I don’t like to wrap classes into other classes. The kind of code this produces is exactly the kind of useless boilerplate code I want to get rid of by using a flexible data binding system like WPF’s. If it can’t be helped, this kind of code should be generated, but that is not the topic of this blog.
- Validation on the ViewModel or Business level removes validation logic and error messages from the domain of the user interface definition to the domain of business logic. Now I like my business logic to be language independent, and it is absolutely valid for a user interface to implement different (more restrictive) checks on a property value than the business object it accesses. So, even if validation logic is implemented on the business level, I want to be able to choose how to use it and what error messages to display on the UI level, i.e. in XAML.
That said, ValidationRules have another significant advantage: they can check values before they are passed to the properties of the bound object. This means that I don’t have to implement rollback capabilities on the business object, but can make sure on the UI level that only valid values are set on the business object. This will be covered in a later post.
With all these advantages, there is a serious drawback to ValidationRules: defining them in XAML is rather unwieldy. Done the traditional way, they tend to bloat the XAML code, and sometimes it is difficult to get at all the reference data they need for their checks.
This is where WPFGlue comes into the picture: here, I want to introduce some ideas which allow to define and apply ValidationRules in a more concise manner, and to do some basic checks even without specifying ValidationRules explicitly.
The BindingGroup Class
The BindingGroup class has been introduced in WPF 3.5 SP1. A BindingGroup can be set on every FrameworkElement. If set, it can define ValidationRules which are able to access multiple properties of the DataContext in order to validate them against each other. In order to afford this possibility, the BindingGroup class provides methods which can access all Bindings in the subtree under the element which defines the BindingGroup, as long as these Bindings have the same DataContext as that element.
The idea here is to use this ability of the BindingGroup class in order to set up ValidationRules for all bindings which share a given DataContext.
So, in order to validate objects of a given class, first of all one would use a container like a StackPanel, Grid or GroupBox to combine a group of controls which share an instance of that class as their DataContext. Then, one would create a BindingGroup object and set it to the BindingGroup property of that container. Further, one would define a set of ValidationRules for a given class. Some of them would be at the property level, others would access multiple properties, as would be normal for ValidationRules on a BindingGroup object. Then, one would apply this set of ValidationRules to the container, instead of the separate controls which edit the object’s properties. One could reuse the set of ValidationRules wherever an instance of the DataContext class was used.
Using the BindingGroup’s ability for finding Bindings which have the same DataContext, one would add the ValidationRules to the appropriate Bindings inside the container.
How to Modify Bindings Which are Defined in XAML
The documentation says that Bindings can not be modified after they have been used. However, there is an event that comes right between the time when the Bindings have all been created, and when they are used for the first time: Initialized. If the DataContext is not null and a BindingGroup is present on a FrameworkElement, this BindingGroup can access and modify those Bindings during the FrameworkElement’s Initialized event.
So, one would need a couple of things:
- A way to define sets of ValidationRules.
- A Sticky Component which handles distributing the ValidationRules to the Bindings.
- A Sticky Property which attaches an instance of a set of ValidationRules to a container.
Defining Sets of ValidationRules
First of all, I said that I wanted to be able to define error messages in XAML. Using the techniques from the WPFGlue Localization namespace, I can handle multiple languages quite conveniently in XAML, and there might be other considerations like the intended audience of an application which might induce me to change the text of error messages. So, my first addition to a WPFGlue ValidationRule base class would be a Message property, which allows me to set the error message in XAML. In addition to that, I just added the functionality to format the property value into the error message.
Public MustInherit Class ValidationRule
Inherits System.Windows.Controls.ValidationRule
Private _Message As String = String.Empty
Public Property Message() As String
Get
Return _Message
End Get
Set(ByVal value As String)
_Message = value
End Set
End Property
Public Overrides Function Validate(ByVal value As Object, ByVal cultureInfo As System.Globalization.CultureInfo) As System.Windows.Controls.ValidationResult
Dim result As ValidationResult = ValidationResult.ValidResult
If Not ValidateCore(value, cultureInfo) Then
Dim message As String = Me.FormatMessage(value)
result = New ValidationResult(False, message)
End If
Return result
End Function
Protected MustOverride Function ValidateCore(ByVal value As Object, ByVal cultureInfo As System.Globalization.CultureInfo) As Boolean
Protected Overridable Function FormatMessage(ByVal value As Object) As String
Return String.Format(Me.Message, value)
End Function
End Class
End Namespace
The set of ValidationRules would be defined as a resource in XAML. In order to be able to do that, I create several classes which allow to define collections of ValidationRules grouped by property name:
<System.Windows.Markup.ContentProperty("Setters")>
Public Class ValidationRuleSetter
Inherits DependencyObject
Implements IStickyComponent
Private Shared _DummyDataContext As Object = New Object
Protected Overridable ReadOnly Property DummyDataContext As Object
Get
Return _DummyDataContext
End Get
End Property
Private _Setters As New PropertyValidationRuleSetterCollection
Public ReadOnly Property Setters As PropertyValidationRuleSetterCollection
Get
Return _Setters
End Get
End Property
The collection Setters contains collections of ValidationRules, grouped under different property names.
The ValidationRuleSetter class is a Sticky Component: in addition to defining the set of ValidationRules, it also has the ability to set the ValidationRules on the Bindings which belong to the container’s BindingGroup. The following method will be called during the container’s Initialized event:
Dim f As FrameworkElement = TryCast(base, FrameworkElement)
If f IsNot Nothing Then
Dim bg As BindingGroup = f.BindingGroup
If bg IsNot Nothing Then
For Each be As BindingExpression In bg.BindingExpressions.OfType(Of BindingExpression)()
If Setters.Contains(be.ParentBinding.Path.Path) Then
For Each v As System.Windows.Controls.ValidationRule In Setters.Item(be.ParentBinding.Path.Path).ValidationRules
be.ParentBinding.ValidationRules.Add(v)
Next
End If
If Setters.Contains(String.Empty) Then
For Each v As System.Windows.Controls.ValidationRule In Setters.Item(String.Empty).ValidationRules
bg.ValidationRules.Add(v)
Next
End If
Next
End If
End If
End Sub
For each Binding that is accessible to the BindingGroup, it looks up the name of the bound property and attaches all ValidationRules which are grouped under that name, if any. By convention, ValidationRules which have an empty String as property name are attached to the BindingGroup itself.
How to Use ValidationRuleSetter on a Container
In order to be able to attach the Sticky Component to a container, one defines a custom attached property like this:
Public Shared Function GetRuleSetter(ByVal d As DependencyObject) As ValidationRuleSetter
Return d.GetValue(RuleSetterProperty)
End Function
Public Shared Sub SetRuleSetter(ByVal d As DependencyObject, ByVal value As ValidationRuleSetter)
d.SetValue(RuleSetterProperty, value)
End Sub
This is actually the standard way of defining a sticky property in the WPFGlue framework.
One would then define the container in XAML like this:
<StackPanel.BindingGroup>
<BindingGroup/>
</StackPanel.BindingGroup>
<TextBox Text="{Binding StringProperty, UpdateSourceTrigger=PropertyChanged}"
Validation.ErrorTemplate="{StaticResource ValidationTemplate}"/>
<TextBox Text="{Binding IntegerProperty, UpdateSourceTrigger=PropertyChanged}"
Validation.ErrorTemplate="{StaticResource ValidationTemplate}"/>
<TextBox Text="{Binding DoubleProperty, UpdateSourceTrigger=PropertyChanged}"
Validation.ErrorTemplate="{StaticResource ValidationTemplate}"/>
</StackPanel>
Side Effects of Using BindingGroups
The presence of a BindingGroup on a container has various effects:
- Any failed ValidationRule on any Binding inside the BindingGroup will make Validation.HasError return true on the container.
- The BindingGroup’s own ValidationRules will cause the Validation.ErrorTemplate to be displayed on the container. ValidationRules on the Bindings will show the ErrorTemplate on the respective control and also the container’s ErrorTemplate.
- The UpdateSourceTrigger on all Bindings inside the BindingGroup will be set to Explicit by default, which means that one would have to call BindingGroup.CommitEdit in order to have the Bindings update their sources. However, if the UpdateSourceTrigger on a Binding is set to another value in XAML, this value will be honoured.
Conclusion
Using this technique, it is possible to separate the definition of validation rules both from the model and from the view. This overcomes the main disadvantage of ValidationRules and opens up the way for further applications.
In posts to come, I intend to cover how to extend this technique in order to do type checks on property values before they are committed to the bound properties, and how to connect this with general data entry handling.
On the Downloads page, you can find the full code of the examples, plus some additions which will be covered in a later post.
WPFGlue goes WPF 4.0
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.
Conclusion
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.
Coding for XAML
XAML is basically a way of describing object structures, which will be instantiated by the XAML parser when a page, resource or template is used. Since one of the ideas in WPFGlue is to configure components in XAML, I had to wrestle a bit with the VS XAML designer and my classes in order to make them work well with each other. This post is about what patterns you can use in order to make classes nice to use in XAML, and how to implement them.
Basics
A XAML tag is basically nothing but a class name and some attributes. The class name stands for the component, the attributes, for its properties. What the XAML parser will do is to create an instance of the class using a parameterless constructor, and to set the properties which have the same names as the attributes to the provided attribute values. So, the basic rules for creating a class for use in XAML are:
- The class must be public.
- It must have a public, parameterless constructor.
- All properties that will be accessed in XAML must be public.
Two other best practices turned out to influence the XAML experience of my custom components, even though I didn’t quite find out why, and I expect this behaviour to change with version 4.0… Well, the problem was that the VS 2008 XAML editor didn’t recognize collection types properly, and that its Intellisense function would suggest every available element, not only the one which are allowed in the collection.
In order to fix that, I did the following:
- Move all components I want to use in XAML to a separate DLL (i.e. not the project they are used in)
- Declare an XML Namespace for this DLL. When I use the components, I don’t declare a XML prefix for their CLR namespace, but use this declared namespace instead.
<Assembly: System.Windows.Markup.XmlnsDefinition("http://wpfglue.wordpress.com/samples/codingforxaml", "CodingForXAML")>
<Assembly: System.Windows.Markup.XmlnsPrefix("http://wpfglue.wordpress.com/samples/codingforxaml", "cfx")>
Using the ContentProperty Attribute
XAML elements can have one or many content elements. A content element is something like the “natural” or most important child element of its parent. It is special because you can set it in XAML without mentioning the name of the property which references it. However, in order to create an object structure, the XAML parser needs to know the property name. Therefore, you can set the name of the property which holds the child element by adding the System.Windows.Markup.ContentProperty(“MyChild”) attribute to the class declaration, where “MyChild” would be the name of the property which holds the child.
If the property is of an collection type, the element can contain multiple child elements, and they will all be added to the collection which the property holds.
Collections for XAML
If you set up your project like I explained in the first section, all you have to do is to derive a collection class from List(Of T) or ObservableCollection(Of T), where T is your item type.
Inherits List(Of XamlCollectionItem)
End Class
Public Class XamlCollectionItem
Private _IntegerValue As Integer
Public Property IntegerValue() As Integer
Get
Return _IntegerValue
End Get
Set(ByVal value As Integer)
_IntegerValue = value
End Set
End Property
End Class
If you do it this way, the XAML will display and compile without problems, and Intellisense will offer you only the available classes of the correct type. Normally, since we are talking about configuring components through XAML, the collection is not expected to change during run time, so it would be enough to use List(Of T).
If you want to use a collection type as the content for an element, you’d have to do the following further steps:
- Create a read-only property which holds an instance of the collection type.
- Initialize it with an empty collection in the elements constructor.
- Set the ContentProperty attribute to the property’s name.
Public Class XamlCollectionParent
Private _Children As New XamlCollection
Public ReadOnly Property Children() As XamlCollection
Get
Return _Children
End Get
End Property
End Class
Referring to Objects by Name I: Keyed Collections
Sometimes you want to refer to be able to refer to specific children of an element. The best way to make sure that you get the correct child is to name the children and to refer to them by name. In XAML, you would do this in a binding’s property path, like this: {Binding Path=MyParentElement.Children[ChildName]}
In order to be able to do that, you’d derive the collection class from KeyedCollection(Of T). Then you’d have to override the GetKeyForItem function, which is supposed to create a unique string key from an item of type T.
Inherits System.Collections.ObjectModel.KeyedCollection(Of String, XamlDictionaryItem)
Protected Overrides Function GetKeyForItem(ByVal item As XamlDictionaryItem) As String
Return item.Key
End Function
End Class
Public Class XamlDictionaryItem
Private _Key As String
Public Property Key() As String
Get
Return _Key
End Get
Set(ByVal value As String)
_Key = value
End Set
End Property
Private _IntegerValue As Integer
Public Property IntegerValue() As Integer
Get
Return _IntegerValue
End Get
Set(ByVal value As Integer)
_IntegerValue = value
End Set
End Property
End Class
You may ask why I don’t use Dictionary(Of TKey, TValue). Well, it seems that XAML’s support for dictionaries is very much geared towards the special needs of ResourceDictionaries, and I believe it is not intended to be used generally. However, KeyedCollection offers you the additional benefit that you can simply iterate over the items and don’t have to worry about mapping Key / Value pairs, since the keys are taken directly from the items.
Referring to Objects by Name II: NameScopes
A NameScope in WPF is what makes element names in a page unique and allows to reference elements by name using their x:Name attribute. If you have a tree structure of elements, but need to reference single elements by name also, a NameScope is the thing to use.
A Namescope is defined through a root element XAML. All descendants of this element which have an x:Name attribute will automatically be registered to the Namescope. In order for this to work, you have to do the following:
- The class which is the root element has to implement the System.Windows.Markup.INameScope interface. Internally, the implementation can be based on the NameScope class, which comes with the WPF framework.
- The classes which are used as descendants of the root element need to use the System.Windows.Markup.RuntimeNameProperty attribute in their declaration, so that the XAML parser knows which property of the class stores the name.
- In order to access the items by name, one needs an indexer. XAML is a little bit limited in its support for indexed properties: you have to have a class which declares the indexer as its default property. In order to provide indexed access to the named elements, this examples uses a nested class which does nothing but find the elements through its parent’s NameScope.
Public ReadOnly Property Node() As NamescopeIndexer
Get
Return _Indexer
End Get
End Property
Public Class NamescopeIndexer
Private _Root As XamlNamescopeRoot
Friend Sub New(ByVal root As XamlNamescopeRoot)
MyBase.New()
_Root = root
End Sub
Default Public ReadOnly Property Item(ByVal name As String) As NamescopeNode
Get
Return _Root.Namescope.FindName(name)
End Get
End Property
End Class
Markup Extensions
Markup extensions are helpful in situations where you have to do more complicated things than just creating an instance of a class and assign it some values. For example, you can use a Markup extension if you want to establish a binding, or if you want to access a backing store which itself is not accessible to XAML, like application settings, localized resources or a configuration file.
However, I am not very fond of markup extensions. They are basically a convenience: normally, you can achieve the same using just a more verbose syntax. And the convenience comes at a price:
Markup extensions have to execute well both at runtime and in the VS designer. Both environments are radically different, and it is not trivial to find out the difference from inside the markup extension. Also, if there is any problem in design mode, there is no debugging support, since the designer always uses the release compiled version of the markup extension. Moreover, I even couldn’t use structured error handling inside the class, since my catch blocks never were called, and sometimes VS crashes when compiling or editing markup extensions.
Anyway, for the sake of completeness, here what I learned:
- Derive a markup extension from System.Windows.Markup.MarkupExtension and override the ProvideValue method.
- Set the MarkupExtensionReturnType attribute to the correct type.
- If the type of the serviceProvider parameter is System.Windows.Markup.ProvideValueServiceProvider, you are in runtime mode, otherwise, you are in design mode.
- Use serviceProvider.GetService(GetType(IProvideValueTarget)) in order to retrieve information about the property which will receive the value. If the TargetProperty parameter is of type DependencyProperty, the property is a dependency property and you can do things like set up a binding, so that the value will be updated automatically if the underlying data source changes.
- Always return a valid value of the correct type, even if the value is some message like “I couldn’t find what you wanted”.
- Whatever you do, avoid exceptions in the ProvideValue method at all costs. In this case this doesn’t mean “catch”, but really “avoid”, since structured exception handling doesn’t seem to work when the extension is used in the designer.
Reporting Configuration Errors
As a rule, your component shouldn’t raise any exceptions if it doesn’t have all the information it needs to do its job, but just make do without it, using intelligent default behaviour or gracefully reducing the functionality. However, sometimes you just have to report something.
In this case, you can raise an ArgumentException with an appropriate message in the property setter which receives the invalid value. Exceptions that are raised in this way will show up in the VS Error List and keep the project from building.
Other Best Practices
- Don’t do complex things like e.g. accessing a database in a constructor. Constructors will run at design time as well as at run time. So, if they need information from the application they are running in, this information might not be accessible at design time. Therefore, one might see strange error messages at design time which are difficult to debug.
- Don’t rely on a certain order in which the properties of your component should be set. If you need several property values in order to do a job, either don’t access the values until you need to do the job, or check whether you have a complete set of values each time any of the properties changes, and start the job as soon as you have a valid set of values.
Conclusion
If you follow these guidelines, your components will behave similar to the components that come with the WPF framework, and they will integrate into the support given by the VS XAML editor.
There are some other techniques which I haven’t covered here, but which I would like to mention: using dependency properties and using type converters. You can find examples for dependency properties all over this blog, e.g. here: http://wpfglue.wordpress.com/2009/12/16/the-sticky-viewmodel-pattern/ . An example for using type converters is given in this post: http://wpfglue.wordpress.com/2009/11/30/css-class-equivalent-in-wpf/ . Otherwise, you will find the patterns which I discussed here everywhere in the WPFGlue code. A special example project for this post is available for download here:
(as always on wordpress.com, you will have to rename it to a .zip extension in order to extract it).
Implementing the Sticky Command Design Pattern
The Sticky Command design pattern is one of the patterns in WPFGlue which allow to add custom functionality to out-of-the-box WPF controls. Adding a Sticky Command to a FrameworkElement gives it a certain new behaviour, and makes this behaviour available to the element and all its child elements through a routed command, while the implementation of the element remains separate and independent of the implementation of the behaviour.
Let’s take an example. A very common need in data oriented applications is a submit command which sends the values of a group of controls to the underlying data store. This command should be disabled when the data is invalid, and it should be possible to connect it to a KeyGesture which allows to call the command by pressing a given key when entering data.
<GroupBox x:Name="CustomerGroupBox" Header="Customer" v:Submit.Command="{StaticResource SubmitCommand}" v:Submit.KeyGesture="Enter"> <!—- Content left out for clarity --> </GroupBox>
The Sticky Command is stuck to the GroupBox by setting the Submit.Command Sticky Property. Optionally, one can add a KeyGesture which invokes the command, in this case pressing the Enter key. The SubmitCommand is just a standard RoutedCommand:
<Window.Resources> <RoutedCommand x:Key="SubmitCommand"/> </Window.Resources>
By itself it doesn’t provide any functionality; it’s just kind of an identifier for the behaviour we want to add to the GroupBox.
Creating a Sticky Property
A Sticky Property is an attached property that, in addition to storing a value on the target element, does some work in its PropertyChanged handler. In our case, this work consists of creating a CommandBinding and setting it on the target element, or removing the created CommandBinding, respectively.
Public Class Submit Inherits DependencyObject Public Shared ReadOnly CommandProperty As DependencyProperty = _ DependencyProperty.RegisterAttached("Command", _ GetType(RoutedCommand), GetType(Submit), _ New PropertyMetadata(AddressOf OnCommandChanged)) Public Shared Function GetCommand(ByVal d As DependencyObject) _ As RoutedCommand Return d.GetValue(CommandProperty) End Function Public Shared Sub SetCommand(ByVal d As DependencyObject, _ ByVal value As RoutedCommand) d.SetValue(CommandProperty, value) End Sub Private Shared Sub OnCommandChanged(ByVal d As DependencyObject, _ ByVal e As DependencyPropertyChangedEventArgs) Dim f As FrameworkElement = TryCast(d, FrameworkElement) If f IsNot Nothing Then If e.OldValue IsNot Nothing Then Detach(f, e.OldValue) End If If e.NewValue IsNot Nothing Then Attach(f, e.NewValue) End If End If End Sub '... End Class
The implementation of OnCommandChanged is quite simple: if the property already has a value, the command should be detached from the target, and if a new value is provided, this value should be attached to it. One might ask why it is necessary to provide a Detach procedure as well. Why not just leave the CommandBinding in place? If the command can be removed by changing setting the value of Submit.Command to Nothing, then the command can be attached and detached through triggers, which opens up a whole new line of uses…
Attaching and Detaching the CommandBinding
Private Shared Sub Attach(ByVal d As FrameworkElement, _ ByVal command As RoutedCommand) d.CommandBindings.Add(New SubmitCommandBinding(command)) Dim gesture As KeyGesture = GetKeyGesture(d) AttachKeyGesture(d, command, gesture) If d.BindingGroup Is Nothing Then d.BindingGroup = New BindingGroup End If End Sub Private Shared Sub Detach(ByVal d As FrameworkElement, _ ByVal command As RoutedCommand) For Each b As SubmitCommandBinding In _ d.CommandBindings.OfType(Of SubmitCommandBinding)() d.CommandBindings.Remove(b) Next DetachKeyGesture(d) End Sub
The Attach procedure creates a new CommandBinding that connects the provided RoutedCommand to its implementation, and adds it to the targets CommandBindings collection.
The Detach procedure removes the CommandBinding from the collection. In order to be able to find the correct CommandBinding, Attach uses a class derived from CommandBinding, in order to use its type as marker. This way, one doesn’t have to store a reference to the created CommandBinding in order to be able to remove it later. The dummy class is a private nested class inside the Submit class:
Private Class SubmitCommandBinding Inherits CommandBinding Public Sub New(ByVal command As RoutedCommand) MyBase.New(command, AddressOf OnExecutedSubmit, _ AddressOf OnCanExecuteSubmit) End Sub End Class
The Command’s Implementation
The procedures OnExecutedSubmit and OnCanExecuteSubmit handle the RoutedCommand.CanExecute and RoutedCommand.Executed events that are sent out by the CommandBinding. It is useful to separate the code specific to event handling from the code that does the actual work:
Private Shared Sub OnCanExecuteSubmit(ByVal sender As Object, _ ByVal e As CanExecuteRoutedEventArgs) Dim result As Boolean = False Dim target As FrameworkElement = TryCast(sender, FrameworkElement) If target IsNot Nothing Then ' Separate event specific code from domain specific code... result = CanExecuteSubmit(target,e.Parameter) End If e.CanExecute = result e.Handled = True End Sub Public Shared Function CanExecuteSubmit(ByVal target As FrameworkElement, _ ByVal parameter As Object) As Boolean Dim result As Boolean = False If target IsNot Nothing Then result = (target.BindingGroup IsNot Nothing AndAlso Not _ System.Windows.Controls.Validation.GetHasError(target)) End If Return result End Function Private Shared Sub OnExecutedSubmit(ByVal sender As Object, _ ByVal e As ExecutedRoutedEventArgs) Dim target As FrameworkElement = TryCast(sender, FrameworkElement) If target IsNot Nothing Then If CanExecuteSubmit(target, e.Parameter) Then ExecuteSubmit(target, e.Parameter) End If e.Handled = True End If End Sub Public Shared Sub ExecuteSubmit(ByVal target As FrameworkElement, _ ByVal parameter As Object) target.BindingGroup.UpdateSources() End Sub
Providing a KeyGesture
In order to be able to specify a KeyGesture for the command on the target, we need to create a second Sticky Property, which is able to add the KeyGesture to the target’s InputBindings collection. The method is similar to the one used with the CommandBinding itself. However, there is one point of note: We cannot be sure of the order in which the attached properties are set on the target. So, we have to make sure that CommandBinding and InputBinding are set up correctly no matter which is specified first. Since the InputBinding depends on the CommandBinding, one could say that Submit.Command is the main Sticky Property, while Submit.KeyGesture is a supporting Sticky property. The rule would then be that the Attach and Detach procedures for the main Sticky property would have to call the Attach procedures for all supporting properties in turn, while the Attach procedures of the supporting properties only attach something if the main Sticky Property has already been set.
The implementation of the KeyGesture functionality looks like this:
Public Shared ReadOnly KeyGestureProperty As DependencyProperty = _ DependencyProperty.RegisterAttached("KeyGesture", _ GetType(KeyGesture), GetType(Submit), _ New PropertyMetadata(AddressOf OnKeyGestureChanged)) Public Shared Function GetKeyGesture(ByVal d As DependencyObject) _ As KeyGesture Return d.GetValue(KeyGestureProperty) End Function Public Shared Sub SetKeyGesture(ByVal d As DependencyObject, _ ByVal value As KeyGesture) d.SetValue(KeyGestureProperty, value) End Sub Private Shared Sub OnKeyGestureChanged(ByVal d As DependencyObject, _ ByVal e As DependencyPropertyChangedEventArgs) Dim f As FrameworkElement = TryCast(d, FrameworkElement) If f IsNot Nothing Then If e.OldValue IsNot Nothing Then DetachKeyGesture(f) End If If e.NewValue IsNot Nothing Then AttachKeyGesture(f, GetCommand(f), e.NewValue) End If End If End Sub Private Shared Sub AttachKeyGesture(ByVal d As FrameworkElement, _ ByVal command As RoutedCommand, _ ByVal gesture As KeyGesture) If command IsNot Nothing And gesture IsNot Nothing Then d.InputBindings.Add(New SubmitKeyBinding(command, gesture)) End If End Sub Private Shared Sub DetachKeyGesture(ByVal d As FrameworkElement) For Each i As SubmitKeyBinding In _ d.InputBindings.OfType(Of SubmitKeyBinding)() d.InputBindings.Remove(i) Next End Sub Private Class SubmitKeyBinding Inherits InputBinding Public Sub New(ByVal command As RoutedCommand, _ ByVal gesture As KeyGesture) MyBase.New(command, gesture) End Sub End Class
Reusability
Once we have this submit command, we can reuse it as it is, in any project, with any kind of control or data. But what about reusability of the pattern implementation itself?
The whole Submit class consists of static members, only. This has the advantage of not creating dependent object references with the command bindings, which could interfere with the garbage collection of the page on which the command is used. Unfortunately, shared members cannot be overridden, which means that it is not straight forward to create a common base class for Sticky Commands and derive new implementations from that class. However, the domain specific code and the pattern specific code are quite easy to separate into different procedures, so that it might be an option to use Item Templates or Code Snippets in order to reuse the pattern specific code.
Conclusion
The Sticky Command pattern offers a powerful and flexible way of modifying the behaviour of standard controls without changing their implementation. Because it is used through declarative syntax, it can leverage the full power of WPF style, trigger and template mechanisms. In addition to that, a new implementation of the pattern can be created from an existing one with minimal changes.
Downloads
The example solution on the Downloads page contains a project called SubmitCommandExample which has the complete code for this example.
Localized Value Formatting in WPF
When I introduced the WPFGlue localization components, I concentrated mainly on displaying localized strings and other static information in the user interface. Today I want to complete the WPFGlue localization section by discussing localized value formatting.
The Problem
Number and date formats vary from culture to culture. 30/12/2009, 12/30/2009 and 30.12.2009 all refer to the same day, and 12.345,67 and 12,345.67 are actually the same number, but will turn out very different if the computer doesn’t know which format the user assumed. Since the early days of computers, this problem has been solved by defining the culture under which the system runs as a system property. Then there would be a set of predefined formats for each given culture which implement the usual standards in that culture. Applications would take number and date formats from these system settings, so they could use the local standards even though they were developed in a different language.
A special case of this problem are enumerated lists. Usually, there is a short text that describes each option. In a localized application, this text should be translated according to the current culture, and it would also be necessary to sort the list differently in different languages in order to keep up an alphabetic order of the items.
Specifying the Formatting Culture in WPF
In WPF, value formatting is part of data binding: if a control needs to display a bound value, it converts it into a string and displays the string. The culture which is used can come from three sources:
- Default: if you don’t do anything special to tell the system from which culture it should derive its number and date formats, it will just take standard US English. Makes sense to define one culture so that by default the application will look the same on whatever system it runs. But actually, in the rest of Dot.NET the rule is that the application should take the installed system culture as default for these purposes, so WPF breaks the expectations of especially us poor Non-Americans…
- The Language property or xml:lang attribute: WPF FrameworkElements have a Language property, which can accept a IETF language tag like en-US or de-DE, and will set the date and number formats according to this language and culture’s properties. The definitions for the formats come from a set of preinstalled cultures which are part of the Dot.Net framework. The Language property is inherited, so if it is specified on top of a page, it will take effect on the whole page.
- The ConverterCulture property on the Binding: This property accepts a Globalization.CultureInfo object. This object might come from any source. Especially, if the user changed the standard number and date formats on the system using the Language and Regional Settings in Control Panel, these changes will be visible in the CurrentCulture object of the application, while they won’t be visible if one just sets the Language property.
So, setting the ConverterCulture on the bindings would be the preferred way to respect the system’s and user’s formatting preferences. However, there are two drawbacks: first of all there is no built-in way to get at the system culture in XAML, and second one would have to specify the culture on each and every binding, since there is no way to apply this setting in a way that is global to the application.
In order to solve this problem, I added another MarkupExtension to the WPFGlue localization namespace: Binding. This is actually nothing more than a normal Binding with the ConverterCulture preset to the CurrentCulture of the system:
Public Class Binding
Inherits System.Windows.Data.Binding
Public Sub New()
MyBase.New()
ConverterCulture = System.Globalization.CultureInfo.CurrentCulture
End Sub
Public Sub New(ByVal path As String)
MyBase.New(path)
ConverterCulture = System.Globalization.CultureInfo.CurrentCulture
End Sub
End Class
End Namespace
So, one can use it everywhere instead of the default Binding, and get date and number formats that behave according to the system settings. I’m not especially proud of this solution, but for the time being it seems to be the best compromise.
The LocalizationExample which you find in the WPFGluePublished solution on the Downloads page demonstrates this behaviour. This XAML code:
<Page.Resources>
<s:DateTime x:Key="Value">#12/30/2009#</s:DateTime>
</Page.Resources>
<Grid>
<StackPanel HorizontalAlignment="Center" VerticalAlignment="Center" >
<TextBlock Text="{l:String TestString}" />
<TextBlock Text="{Binding Source={StaticResource Value}}"/>
<TextBlock Text="{l:Binding Source={StaticResource Value}}"/>
<Image Stretch="None" Source="{l:BitmapImage FlagURI}"/>
</StackPanel>
</Grid>
</Page>
produces the following output:
Notice that setting the page’s Language property to the UILanguage (German in my case) causes the first binding to display its value in the default German date format, while using the localized binding causes the same value to be displayed in the format YYYY-MM-DD, which is what I specified in Control Panel as the standard short date format.
Localized Lists
In Dot.NET, sets of options can and should be summarized in enumeration types, with a named constant for each available option. The Dot.NET formatting engine, which is called through the String.Format method, supports converting the numeric enumeration values to strings and vice versa using the constant names that are defined for the enumeration in code. However, this option is only useful for debug output. If the values must be displayed to users, they must be translated into their languages, and actually this is not the job of the code which defines the enumeration.
A user interface which wants to use enumeration values needs the following functions:
- translate numerical values to string descriptions (for read-only display of values).
- translate string descriptions into numerical values (for cases where the user can enter text).
- create a mapped list of values and descriptions (for ComboBoxes and the like where the user just picks a value from a list).
The LocalizedList class provides these functions. It works both as a collection of value / description pairs and as a IValueConverter that converts the descriptions forwards and backwards.
In order to define a LocalizedList, you have several options:
- Just set the ValueEnum to an enumeration type and let the LocalizedList generate the entries from the enumeration’s definition (actually, this is not localizing anything yet…)
- Set the LocalizedList’s Definition property to a string in the format “value1=name1,value2=name2…”, where the values are the constant names or values from the enum definition, and the names the localized display names. Typically, the definition string would itself be a localized string resource.
- Define Entry objects directly in the XAML, which map string keys to arbitrary typed values.
The definition string format is actually quite flexible. So, you can change the default list and value separator characters (“,” and “=”). You could also leave out the values and just specify the enumeration type, so that the LocalizedList assumes that you specified the descriptions for the numeric values in their natural order. On the other hand, you could specify both names and values, but change the order, or use a subset of the available values, only. And finally, you could leave out the ValueEnum altogether and use String codes instead, as it is done in the language selection list in the example:
where e.g. the English version of the referenced string resource is
de-DE=German,en-US=English,ar-SA=Arabic
The other LocalizedList in the example maps String keys directly to objects:
<l:Entry Key="{l:String InternalLabel}" Value="{x:Null}"/>
<l:Entry Key="{l:String ExternalLabel}" Value="{x:Type r:Dummy}"/>
</l:LocalizedList>
Using this list, it is possible to change the resource assembly of the example purely in XAML, with no code behind:
DisplayMemberPath="Key" SelectedValuePath="Value"
SelectedValue="{Binding RelativeSource={RelativeSource
Mode=FindAncestor, AncestorType={x:Type NavigationWindow}},
Path=(l:Localization.ResourceReferenceType)}"/>
Conclusion
Using localized resources on the one hand and providing localized value formatting on the other hand are about all that comes to my mind under the heading of localization. I’ll be glad to react to feedback or criticism…
The Sticky ViewModel Pattern
A Sticky ViewModel is a special type of Sticky Component which adds functionality to the ViewModel instead of to the View. By binding to the DataContext of its base element, the Sticky ViewModel is able to provide services which the ViewModel itself doesn’t include. In this respect, it is similar to the Mini-ViewModel pattern, which you might prefer if you want to provide an encapsulated reusable View for the added functionality as well.
An Example
The model or ViewModel might have a property which contains a persons name. In the View, you might want to be able to edit first name and last name separately. I have already discussed this example in the context of the Stateless Sticky ViewModel pattern, so here I want to add some extra: the new implementation should format the name either John Smith or Smith, John, depending on a boolean property LastNameFirst which one can use to configure the behaviour.
The example is contained in the StickyComponentExample project which you will find in the WPFGluePublished solution on the Downloads page.
Using a Sticky ViewModel
Like any other Sticky Component, you would initialize a Sticky ViewModel in the resources of an element that wants to use them:
<ex:NameStickyViewModel x:Key="viewModel"
LastNameFirst="True" FullName="{f:StickyBinding Name}"/>
</Grid.Resources>
Using the LastNameFirst property, we specify that we want the full name displayed in the Smith, John format.
But what is the meaning of the {f:StickyBinding } markup extension? It is understood that the Sticky ViewModel somehow accesses the DataContext of its base element in order to enhance it. In fact, there is a DataContext property in the StickyViewModel base class which is synchronized with the base’s DataContext automatically.
However, if the Sticky ViewModel would get the information it needs directly from the DataContext, it would have to know its type, thus being closely coupled to the ViewModel, which we want to avoid, since we want to be able to re-use the Sticky ViewModel wherever we need its functionality. So, the idea is to get the necessary information from the DataContext through data binding. Unfortunately, since the Sticky ViewModel is not part of the logical WPF tree, normal bindings cannot access the base element’s DataContext implicitly, like child controls. So, we use a special binding class, the StickyBinding, which allows us to bind to the DataContext of the StickyViewModel, instead. By writing FullName=”{f:StickyBinding Name}” we instruct the StickyViewModel to look for the value it should edit in the Name property of the model the element is bound to.
As usual, the Sticky ViewModel is attached to its base through an attached property:
ex:NameStickyViewModel.ViewModel="{DynamicResource viewModel}"
HorizontalAlignment="Stretch">
In this case, we have to refer to it with a DynamicResource extension, since it is contained in the resources of the element it is used on and thus is referred to before it is declared. We could also put it into the page’s resources and use a StaticResource extension. (StaticResource extensions are less complicated, so they are a little bit safer and faster, but they can only be specified where the definition comes before the reference in the XAML). However, in the example, the NameStickyViewModel is used in a DataTemplate for a ListView. So, every row of the ListView needs its own instance of the Sticky ViewModel, otherwise the names from different rows will start mixing. We can make sure of this either by putting the declaration of the StickyViewModel into the DataTemplate itself, as I have done here, or by setting x:Shared=”False” where we declare it, which tells WPF to create a new instance of a resource every time it is accessed.
The rest of the DataTemplate defines three TextBoxes for each row:
Margin="30,0,0,0"/>
<TextBox Grid.Column="1" Text="{Binding ElementName=base,
Path=(ex:NameStickyViewModel.ViewModel).LastName}"/>
<TextBox Grid.Column="2" Text="{Binding ElementName=base,
Path=(ex:NameStickyViewModel.ViewModel).FirstName}"/>
The first TextBox is bound directly to the DataContext of the DataTemplate. It refers to the property in the model that contains the full name of a person. The other two TextBoxes are bound to the StickyViewModel that lives on the element named “base”; this element is the Grid from above.
Implementing the Sticky ViewModel Pattern
In order to support binding on their properties, Sticky ViewModels are derived from DependencyObject and expose their working properties as DependencyProperties. Configuration properties don’t need to be data bound, so they are defined as normal properties.
Like in the Stateless Sticky ViewModel, after implementing the logic which does what the model should do, the main point is distributing the change notifications from the different properties so that the logic is called at the right time. This happens in the OnPropertyChanged method of the Sticky ViewModel, which is originally defined in DependencyObject:
MyBase.OnPropertyChanged(e)
Static changeInitiator As DependencyProperty = Nothing
If changeInitiator Is Nothing Then
changeInitiator = e.Property
Select Case e.Property.Name
Case "FullName"
FirstName = DetermineFirstName(FullName)
LastName = DetermineLastName(FullName)
Case "FirstName", "LastName"
FullName = DetermineFullName(FirstName, LastName)
End Select
changeInitiator = Nothing
End If
End Sub
Again like in the Stateless Sticky ViewModel, we remember between invocations which property started the change and cancel subsequent invocations of the method. However, this time the code is a little bit shorter and cleaner and not distributed between different methods (I just notice that one could implement it the same way with a Stateless Sticky ViewModel, but alas… never get it perfect the first time.)
Under the Hood
The Sticky Component Framework supports the Sticky ViewModel pattern with two components: the StickyViewModel base class, which can be used to derive one’s own Sticky ViewModels, and the StickyBinding, which one needs to be able to bind to the properties of the Sticky ViewModel’s DataContext.
The StickyViewModel class mainly manages attaching and detaching the ViewModel on its base element:
Me.DataContext = StickyComponentManager.GetDataContext(sender)
StickyComponentManager.AttachDataContextChanged(sender, AddressOf _DataContextChanged)
Attach(sender, e)
End Sub
Public Sub OnDetach(ByVal sender As Object, ByVal e As System.EventArgs) Implements IStickyComponent.OnDetach
Me.DataContext = Nothing
StickyComponentManager.DetachDataContextChanged(sender, AddressOf _DataContextChanged)
Detach(sender, e)
End Sub
It adds a handler to the base’s DataContextChanged event, so that the DataContext stays synchronised with the base’s DataContext. DataContext is a DependencyProperty, so it provides its own change notifications. Furthermore, the class defines a generic ViewModel attached property which can be used in derived classes in order to attach the model to the element.
The StickyBindingExtension basically is a BindingExtension with a reduced set of properties (everything related to input and validation is not needed on the StickyBinding), and in principle delegates all it does to this binding:
Dim target As System.Windows.Markup.IProvideValueTarget = serviceProvider.GetService(GetType(System.Windows.Markup.IProvideValueTarget))
If target IsNot Nothing Then
If TypeOf target.TargetProperty Is DependencyProperty Then
If TypeOf target.TargetObject Is StickyViewModel Then
Dim dataPath As String = "DataContext"
If Not String.IsNullOrEmpty(Path) Then
If Path.StartsWith("/") Or Path.StartsWith("[") Then
dataPath &= Path
Else
dataPath &= "." & Path
End If
End If
Dim b As New Binding(dataPath)
b.Source = target.TargetObject
b.Mode = Mode
b.Converter = Converter
b.ConverterCulture = ConverterCulture
b.ConverterParameter = ConverterParameter
Return b.ProvideValue(serviceProvider)
End If
End If
End If
Return Me
End Function
The trick here is to prefix the binding’s path with the DataContext property and always use the target object as source. Thus, following the principles of WPFGlue, I avoid to implement my own version of change notification listeners and instead use what is already there. Since the DataContext is always synchronized with the the base’s DataContext and provides change notification, the StickyBinding will always be able to find the correct property without any explicit dependencies.
Notice that the last line in the block that creates the binding returns Binding.ProvideValue. This is necessary in order to mimic Binding’s behaviour in all contexts.
Comparing Stateless and Stateful Sticky ViewModel
As mentioned before, the main advantage of the Stateful Sticky ViewModel is that it bundles configuration properties in one place and forms a better defined unit than the Stateless version. Its main focus is on the base’s DataContext. Sticky Bindings don’t support binding to properties of elements in the logical tree, as it would be possible with the ElementName or RelativeSource properties of a normal binding. However, if one needs that, one can combine the two patterns and define attached properties on the Sticky ViewModel for no other purpose than to be able to bind them to logical tree elements, and access them through a reference to the base that is acquired during Attach and of course released during Detach.
Coming Soon…
The Sticky Component Framework is still once removed from a real application… the next step will be a Commanding Framework based on Sticky Components which allows to define RoutedCommands, their keyboard shortcuts and display texts in one place, delegating their invocations to methods or ICommand implementations in the ViewModel or model.
Using Validation.ErrorTemplate
This was originally published as a thread in the MSDN WPF forum before I started this blog. However, today I revisited the thread and decided to maintain it here, now..
There are a couple of known problems and unknown features with Validation.ErrorTemplate that came up frequently, and I’d like to collect the workarounds for these things in one place. This is how far I got:
Problem: The Content of the ErrorTemplate is not displayed correctly
e.g. the red border doesn’t fit around the control, or parts of the error template are not drawn. The reason is that there may not be enough space around the control to display the error template, so the solution is to make the margin of the control big enough that the error template can be drawn.
Unknown Feature: The DataContext of the ErrorTemplate is the Validation.Errors Collection
Haven’t found this in the documentation, but it means that the easiest way to get at an error message in an error template is to use {Binding Path=/ErrorContent}.
Problem: Have to Change the Style of a Control in Order to Set the Error Message as ToolTip
It seems to be impossible to set the ToolTip of a control using Styles or Triggers in the error template. Usually this is worked around by modifying the Style of the control, as in the example from the WPF SDK. However, this has the disadvantage that one has to change the style of the control in order to accommodate Validation, which might interfere with other uses of the Style. There are better workarounds: most elegant by using a ToolTip on some error indicator that is part of the error template, or, if it must be the control itself, using a custom attached property on the AdornedElementPlaceholder like this:
Public Shared Function GetAdornedElementToolTip(ByVal d As DependencyObject) As Object
Return d.GetValue(AdornedElementToolTipProperty)
End Function
Public Shared Sub SetAdornedElementToolTip(ByVal d As DependencyObject, ByVal value As Object)
d.SetValue(AdornedElementToolTipProperty, value)
End Sub
Private Shared Sub OnAdornedElementToolTipChanged(ByVal d As DependencyObject, ByVal e As DependencyPropertyChangedEventArgs)
Dim placeholder As AdornedElementPlaceholder = TryCast(d, AdornedElementPlaceholder)
If placeholder IsNot Nothing Then
Dim control As Control = TryCast(placeholder.AdornedElement, Control)
If control IsNot Nothing Then
control.ToolTip = e.NewValue
End If
End If
End Sub
One can bind the error message to this property, and this way the error template works without interfering with the control’s style.
Problem: The Error Template is not Displayed when a Page is Loaded
This is by design, since one could assume that the user doesn’t want to see error messages before he/she made any mistakes, but sometimes one needs this functionality. So, the ValidatesOnTargetUpdated property was introduced on the ValidationRule class; by setting it to true, one sees the validation result immediately.
However, there is one caveat: you must make sure that you set the DataContext after the page is initialized; this would be either in the constructor after the generated comment line that says that initialization code should go there, or in the Loaded event. If you want to set the DataContext in XAML, you find a solution for this problem here (among other things): http://wpfglue.wordpress.com/2009/12/08/navigating-from-object-to-object/
Anyway, I hear this will be fixed in WPF 4.0.
Problem: When Using an Expander, the Error Template Remains Visible even if the Expander is Collapsed
This problem is a known bug, unfortunately as far as I know not yet scheduled for fixing. The workaround (found in the MSDN WPF forum) is binding the Visibility property of the outermost element of the error template to the AdornedElement.IsVisible property of the AdornedElementPlaceholder, using the BooleanToVisibilityConverter that comes with WPF.
Standard Error Template
So, this would be my standard error template:
<Border BorderBrush="Red" BorderThickness="1">
<Border.Visibility>
<Binding ElementName="placeholder" Path="AdornedElement.IsVisible">
<Binding.Converter>
<BooleanToVisibilityConverter/>
</Binding.Converter>
</Binding>
</Border.Visibility>
<StackPanel>
<AdornedElementPlaceholder x:Name="placeholder"
v:Validation.AdornedElementToolTip="{Binding Path=/ErrorContent}"/>
</StackPanel>
</Border>
</ControlTemplate>
And this would be how I use it:
<TextBox x:Name="Abox" Margin="3" Validation.ErrorTemplate="{StaticResource errorTemplate}"
Text="{Binding Path=A, UpdateSourceTrigger=PropertyChanged,
ValidatesOnDataErrors=True}" />
<Expander Header="Test" IsExpanded="True" Validation.ErrorTemplate="{x:Null}">
<Expander.BindingGroup>
<BindingGroup/>
</Expander.BindingGroup>
<TextBox x:Name="Bbox" Margin="3"
Validation.ErrorTemplate="{StaticResource errorTemplate}"
Text="{Binding Path=B, UpdateSourceTrigger=PropertyChanged,
ValidatesOnDataErrors=True}"/>
</Expander>
</StackPanel>
The Sticky Component Framework
What is a Sticky Component? A Sticky Component is a component that can be attached to any FrameworkElement or FrameworkContentElement in order to enhance its functionality, without the need to subclass the element or to write code behind for it. Because of this, Sticky Components can be used very effectively to encapsulate specialized behaviours in a reusable way, and to enhance either the View or the ViewModel of an MVVM application without changing its code.
Sticky Component Interaction Patterns
In order to enhance the functionality of an element, the Sticky Component needs to interact with the element. There are several possible ways to connect the two:
- Through registering event handlers: The Sticky Component can subscribe to events of the element it is attached to, and trigger its own functionality through these events.
- Through registering CommandBindings: The Sticky Component can add its own CommandBindings to the element’s CommandBindings collection, thus enabling the element to handle the specified command.
- Through registering InputBindings: the Sticky Component can enable an element to invoke commands by adding InputBindings to its InputBindings collection.
- Through data binding: the Sticky Component can bind its own properties to the properties of the element. These bindings could in principle have the element as target or as source. But since many properties in the WPF framework are readonly, it is less error prone to always make the Sticky Component the binding target by convention.
- Through binding to the element’s DataContext: a special class of Sticky Component, the Sticky ViewModel, doesn’t enhance the View, but the ViewModel, by binding to its properties and adding functionality that isn’t present in the ViewModel without the need to change it.
Some of these patterns require references between the Sticky ViewModel and the element it is attached to (its “base”). References are dangerous. They may cause memory leaks and unintended behaviour, e.g. if events are handled even if the view that established the event subscription is already out of scope. Therefore, the core of the Sticky Component Framework is concerned with managing the lifetime of a Sticky Component and its interaction patterns so that all these references are cleaned up when appropriate.
Sticky Component Lifetime
The life cycle of a Sticky Component looks like follows:
- It is defined and configured in the Resources of the application, a window, or an individual element.
- It is referenced in an attached property on the base element it is attached to. This is the time when the Sticky Component is actually instantiated.
- It attaches itself to the base. This can happen either immediately or delayed, depending on whether the base must be in initialized or loaded state before the component can attach to it.
The end of the component’s relationship to the base could come in two ways:
- Either the attached property which connects the component to the base is reset,
- or the base itself is unloaded.
In both cases, all references between the Sticky Component and its base should be removed, leaving either object ready for garbage collection. If the component still exists after it has been detached from its base (e.g. because it is kept as a shared instance in a ResourceDictionary), it could be attached again to a different base, or even the same, if that still is available.
This lifetime pattern is expressed in the following interface definition:
Immediate = 0
OnInitialized = 1
OnLoaded = 2
End Enum
Public Interface IStickyComponent
Sub OnAttach(ByVal base As Object, ByVal e As EventArgs)
Sub OnDetach(ByVal base As Object, ByVal e As EventArgs)
ReadOnly Property Mode() As AttachMode
End Interface
OnAttach will be called whenever the Sticky Component will be attached to a base, OnDetach will be called when it is detached. Both methods have EventHandler signatures, so that they can be invoked by the Initialized, Loaded or Unloaded events, respectively. The Mode property defines when the component should attach itself to the element. If possible, the component should attach itself immediately. However, if it needs to modify existing bindings, it will have to do that during the Initialized event, and if it needs to access properties that are data bound, like e.g. the DataContext of the base, it might have to wait until the Loaded event. Since these requirements depend on what the component does, it would be expected that a class that implements IStickyComponent would return a constant value here.
The StickyComponentManager
The StickyComponentManager is a static class that encapsulates the different ways to establish and remove interaction connections between a Sticky Component and its base. It offers overloaded Attach and Detach procedures in pairs with corresponding parameters. So, one would attach an event to a base using the Attach(base,event,handler) overload, and remove it again using the Detach(base, event,handler) overload. There are overloads for all cases discussed here; some of these overloads offer additional services; e.g. there are overloads for attaching event handlers which automatically remove the event handler after it has fired once (using the One Shot Event pattern), or if another specified event occurs before the event that the handler is supposed to handle.
In your Sticky Component, you would set up the connection to the base by calling the appropriate Attach methods of the StickyComponentManager in your OnAttach implementation, and remove the connection by calling the corresponding Detach methods in the OnDetach implementation.
The most important overloads of these methods are the ones that attach / detach Sticky Components. There is a special implementation of a DependencyPropertyChangedHandler that you can use with your attached properties that attach Sticky Components which calls these overloads:
Dim c As IStickyComponent
If e.OldValue IsNot e.NewValue Then
c = TryCast(e.OldValue, IStickyComponent)
If c IsNot Nothing Then
StickyComponentManager.Detach(d, c)
End If
c = TryCast(e.NewValue, IStickyComponent)
If c IsNot Nothing Then
StickyComponentManager.Attach(d, c)
End If
End If
End Sub
This will ensure that the lifetime of the sticky component is managed according to the life cycle described above.
In addition to the Attach and Detach methods, the StickyComponentManager contains several utility methods which hide the difference between FrameworkElement and FrameworkContentElement when attaching Sticky Components. So, elements derived from both of these classes could be the base for Sticky Components; on other elements, the Attach / Detach methods would simply do nothing.
Using Sticky Components
In XAML, you would normally declare and configure a Sticky Component in a Resources section, like this:
Name="UseEvents" UseCommand="False"/>
</Page.Resources>
This would define a Sticky Component of class TestStickyPatterns and configure it by setting its Name and UseCommand properties.
You would then use it on a base element like this:
ex:TestStickyPatterns.Component="{StaticResource UseEvents}">
Test Event Patterns</Button>
If you need the Sticky Component more than once on your page, consider setting the x:Shared attribute to false on its declaration. Thus you make sure that each time the component is used, you start with a fresh instance. Otherwise it could happen that the component is attached to multiple elements on your page at the same time, with unwelcome results.
Implementing Sticky Components
The TestStickyPatterns.Component attached property would be defined like this:
DependencyProperty.RegisterAttached("Component", _
GetType(IStickyComponent), GetType(StickyTestComponent), _
New PropertyMetadata(AddressOf StickyComponentManager.OnStickyComponentChanged))
Public Shared Function GetComponent(ByVal d As DependencyObject) As IStickyComponent
Return d.GetValue(ComponentProperty)
End Function
Public Shared Sub SetComponent(ByVal d As DependencyObject, _
ByVal value As IStickyComponent)
d.SetValue(ComponentProperty, value)
End Sub
Notice that the property metadata refers to the shared (static in C#) method StickyComponentManager.OnStickyComponentChanged in order to enable lifecycle management for the component.
Its OnAttach and OnDetach implementations look as follows:
MyBase.OnAttach(sender, e)
If _UseCommand Then
StickyComponentManager.Attach(sender, MyCommand, AddressOf OnExecuted, Nothing)
StickyComponentManager.Attach(sender, New KeyGesture(Key.Space, ModifierKeys.Control), MyCommand)
Else
StickyComponentManager.Attach(sender, ButtonBase.ClickEvent, AddressOf OnClick)
StickyComponentManager.Attach(sender, ButtonBase.ClickEvent, AddressOf OnClickOneShot, True)
StickyComponentManager.Attach(sender, ButtonBase.ClickEvent, AddressOf OnClickCancel, FocusManager.LostFocusEvent)
End If
End Sub
Public Sub OnDetach(ByVal sender As Object, ByVal e As EventArgs) Implements IStickyComponent.OnDetach
MyBase.OnDetach(sender, e)
If _UseCommand Then
StickyComponentManager.Detach(sender, New KeyGesture(Key.Space, ModifierKeys.Control))
StickyComponentManager.Detach(sender, MyCommand)
Else
StickyComponentManager.Detach(sender, ButtonBase.ClickEvent, AddressOf OnClick)
StickyComponentManager.Detach(sender, ButtonBase.ClickEvent, AddressOf OnClickOneShot)
StickyComponentManager.Detach(sender, ButtonBase.ClickEvent, AddressOf OnClickCancel)
End If
End Sub
Grouping Sticky Components
Since the idea in using Sticky Components is that their behaviour is very narrow and specialized, so that they are suitable for many different contexts, there is a need to be able to group Sticky Components and attach a whole group at once to the same base element. The Sticky Component Framework contains a generic collection to help with that: StickyComponentCollection(Of T as IStickyComponent). This collection attaches and detaches its items at the right times, provides change notification, and if you implement the INamedStickyComponent interface on the collection’s items, you even can refer to the components inside the collection using string indexers in XAML. Here is an example of the use of this collection:
<ex:StickyTestComponentSet x:Key="test2">
<ex:StickyTestComponent Name="Page Immediate"/>
<ex:StickyTestComponent Name="Page OnInitialized" AttachMode="OnInitialized"/>
<ex:StickyTestComponent Name="Page OnLoaded" AttachMode="OnLoaded"/>
</ex:StickyTestComponentSet>
StickyTestComponentSet is defined by inheriting a concrete type instance of the generic collection:
Inherits StickyComponentCollection(Of StickyTestComponent)
Implements IStickyComponent, IList
Notice that for some reason the Visual Studio XAML designer (Cider) will only let you add direct content to the class if you specify “Implements IList” again, even though this interface is already implemented by the base class.
The StickyComponent Example
On the Downloads page you will find the source code for the framework and an example project called StickyComponentExample. This project mainly focuses on demonstrating the different interaction techniques between StickyComponents, their usage patterns, and their life cycle. In order to trace the life cycle, a lot of debug output is written to Debug.Print, so you should run the project in the Visual Studio Debugger and follow the output in the Immediate window.
Coming Soon…
There is one special case of a Sticky Component: the Sticky ViewModel. It deserves special attention, and even though the example is already in the example solution, I’d like to cover it in a separate post.
The Last Word on Localized Resources in WPF
After finishing my last post on using localized resources in WPF, I had the following idea, which I should have included from the start:
If you want to maintain your resources in a more WPF-ish and less WinForms-ish way, just do this:
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:l="http://wpfglue.wordpress.com/localization"
Title="Window1" Height="300" Width="300">
<Window.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="{l:URI MyUriToLocalizedDictionaries}"/>
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</Window.Resources>
Set up your localized resource satellite assemblies like described in the other post, but don’t put anything into them except the pack URI’s of your localized dictionary in the respective language. This way, you can include every type of resource that’s available in WPF, don’t have any WinForms dependencies, and still have the standard .Net way of selecting the right localized resources. You can maintain the consistency of the dictionaries using a normal diff tool, and are no longer annoyed by the Visual Studio resource designer’s bad habit of interrupting your typing while auto-saving and swallowing what you just typed if you are not lucky.
On the downside, however, all localized resources will be part of your main assembly, either directly or by reference, and it is less convenient to add support for new languages, except if you decide to store the resource dictionaries as uncompiled Content files.
