WPF Localised Bindings – What to do when they just don’t seem to work :)


I am currently working on a system in Arabic (no, I don’t understand Arabic), and I bumped into an issue where Bindings were not respecting my CurrentUICulture.

Digging bit deeper (with the help of a handy decompilation tool) I found a not-so-beautiful line in FrameworkElement.cs

public static readonly DependencyProperty LanguageProperty =
DependencyProperty.RegisterAttached("Language", typeof(XmlLanguage),
_typeofThis, new FrameworkPropertyMetadata(XmlLanguage.GetLanguage("en-US"),
FrameworkPropertyMetadataOptions.Inherits | FrameworkPropertyMetadataOptions.AffectsMeasure));

As you can see, WPF does NOT respect your thread’s CurrentUICulture.

The fix is simple… finding it, on the other hand, was a nightmare.

Just override the metadata as follows:

FrameworkElement.LanguageProperty.OverrideMetadata
(typeof (FrameworkElement),
new FrameworkPropertyMetadata(XmlLanguage.GetLanguage(CultureInfo.CurrentCulture.IetfLanguageTag)));

Hope it helps :)

Advertisements

WPF RadioButton problems and MVVM


As some of you might know, the WPF RadioButton control does not play nice with MVVM.

The scenario that I was facing was as follows:

– I have a ViewModel with PropertyA set to True and PropertyB set to False on init.
– I have a View with two RadioButton controls sharing the same group, and bound to PropertyA and PropertyB on the ViewModel

Since in this case I was using a ViewModel-First approach, when the View is created, the RadioButton OnChecked and OnToggle where setting the True and False values for me behind the scenes.

I finally solved this using the following logic in the property setters:

:) Hope this helps someone.

Consuming Routed Events in WPF


In my last post I gave a brief explanation of what a RoutedEvent is all about.  In this blog post I am going to show you how to consume a custom RoutedEvent.

Let’s start off by defining a simple event (in a vanilla WPF Application using the default WPF Application project template in VS2010).

This is covered in more detail in my previous post, yet just to re-summarize:

  1. Declare the static RoutedEvent as a field in your class
  2. Register the RoutedEvent in a static constructor
  3. Raise the event… somewhere

With all that done, we can run the application and see what happens, we are interested in the console output at this point, rather than the app itself (it’s not too fancy anyway!), though if you are following along, clicking a bit on the Window so as to raise the event.

As we can see, the output is as expected.

  1. First the RoutedEvent was registered (in the static constructor)
  2. The Window was initialized (in the instance constructor)
  3. We clicked on the window… and the event was raised (in the overridden OnMouseLeftButtonDown method)

Next up, we may want to actually do something when this event happens, so we make a call to UIElement’s AddHandler method, and register a delegate of type RoutedEventHandler.

Firing it all up now and clicking, produces the following output

Which as expected is invoking our event handler.  But what if we want to register the event handler in our XAML? There is currently nothing public about our event, we therefore have to wrap our event in a standard .NET event handler, and this way expose it to XAML (after importing the namespace).

And following this, we can import the namespace, and register an event handler accordingly (we’ll use the same event handler as before).

Running and clicking on the window, now produces the following:

As you can see, the only real difference is that during the initialization phase, our XAML defined handler was also registered using out event wrapper.

That’s all there is to it.  I hope someone finds this helpful

Defining Routed Events in WPF


Routed events form the event mechanism used for WPF applications.  The basic principle behind routed events is that potentially, anyone in the visual tree (and implicitly the logical tree) can be ‘notified’ of this event if they so wish to.

The concept is that when an event occurs, it will travel both up (bubbling) and down (tunnelling) the visual tree.

Since WPF uses element composition to create UX, you can probably already appreciate how crucial this mechanism is.  Imagine attaching a ‘click’ event handler to a button which never gets fired since you happen to be clicking on the TextBlock that forms the text on the button, or on its border.  Thanks to the bubbling and tunnelling characteristic, you can either choose to handle the event when it reaches the button, or the text, or even both… it’s really up to you.

Routed events are very similar to dependency properties (though instead of the Property suffix, by convention, you’d use an Event suffix… though you don’t have to).  You also need to register a RoutedEvent in the static constructor, followed by a standard .NET event wrapper.  Same as for dependency properties, DO NOT put any logic in the event wrapper itself.

Creating and raising a RoutedEvent

The AddHandler, RemoveHandler and RaiseEvent methods are all defined in System.Windows.UIElement, i.e. the mother class of almost all WPF components.

Routing Strategies

A RoutingStrategy (selected when registering the event), defines how the event is propagated down/up the visual tree.  This is an enumeration that provides easy access to the 3 methods available, tabulated below:

Tunnel The event instance routes downwards through the tree, from root to source element
Bubble The event instance routes upwards through the tree, from event source to root
Direct The routed event does not route through an element tree, but does support other routed event capabilities such as class handling, System.Windows.EventTrigger orSystem.Windows.EventSetter

Routing Event Handlers

Event handlers for routed events follow the same syntax as traditional .NET events and share the same signature tuple.  The first parameter, of type System.Object is a reference to the object to which the handler was attached to, whilst the second parameter is always a type extending System.Windows.RoutedEventArgs (or an instance of RoutedEventArgs), which exposes 4 very useful properties as tabulated below

Handled Gets or sets a value that indicates the present state of the event handling for a routed event as it travels the route
OriginalSource The original reporting source, before any possibleSystem.Windows.RoutedEventArgs.Source adjustment made by class handling, which may have been done to flatten composited element trees
RoutedEvent The System.Windows.RoutedEventArgs.RoutedEvent associated with thisSystem.Windows.RoutedEventArgs instance.
Source A reference to the object that raised the event.

That’s pretty much it. Listening and handling an event follows the normal syntax, and if I find time in the coming days I will write a blog post about a typical scenario of how you would consume a RoutedEvent.

Markup Extensions? What the…


OK, so more XAML mojo and sexiness from me :)

Markup extensions are another way of extending XAML expressiveness (like type converters), and making our XAML even more compact.  WPF already comes with many built-in markup extensions out of the box, but as with anything else, it doesn’t stop us from creating our own.

The whole idea revolves around evaluating a string at runtime (think loosely of JavaScript‘s eval() function, or JEE’s EL language), there are some exceptional cases that are actually compiled, mostly for performance reasons (though I still don’t know which specific cases these are).

If we have a look at our Object Browser, we’ll find a System.Windows.Markup namespace, with an abstract class called MarkupExtension.

We can also see a bunch of classes that derive from it.  These are our ‘Mark Up’ extensions, and exploring these will give you a good idea of what each one does.  These are also all available via the XAML language namespace, generally prefixed using x (as opposed to the WPF controls namespace which is normally the default namespace).

Let’s show an example.

Say we have a Button with an Ellipse as its content

And for some odd reason, we want to set the content property to Null.  We cannot do this using normal property element syntax, so instead, we use property attribute syntax and use a Markup Extension to inject the Null value into the content property, like so

If you’re sharp enough, you may have noticed that I have omitted the ‘Extension’ part of the name, this is allowed by WPF as a form of shorthand notation (though you can very well write the full name).

If you explorer the Object Browser further, you will also note that Binding, Static, Array, RelativeSource, etc… are all actually markup extensions.

There is nothing stopping you from defining your own markup extensions, though you need to remember to import these as a namespace prior to using them, and that they must extend from System.Windows.Markup.MarkupExtension… otherwise the XAML parser WILL complain :)

One other note.  It is also allowed to nest markup extensions ad-inifintum, the most common example being the following:

If you noticed, some parameters are prefixed (like Path=) whilst others are not.  The ones that are not are fed to the extension’s constructor as a string parameter, whilst the others are fed into the already-constructed object’s property setters.  So, in the example above, ‘RelativeSource=’ is referring to the Binding.setRelativeSource(…) setter, and feeding into it a RelativeSource object that has been constructed as new RelativeSource(“self”)… hope this clarifies a few things :)

Demystifying WPF XML namespaces


WPF XML namespaces are those fancy little cryptic strings at the top of every WPF application that you use (generally prefixed with xmlns=”..”, meaning that they are the ‘default’ namespace [i.e. no prefix required]).

But what do they mean?

Simply put, they are ‘short cuts’ to import a whole plethora of .NET WPF assemblies and make their contents available for use in your XAML file.

The most commonly used namespace is http://schemas.microsoft.com/winfx/2006/xaml/presentation, and it imports the following .NET namespaces

  • System.Windows
  • System.Windows.Automation
  • System.Windows.Controls
  • System.Windows.Controls.Primitives
  • System.Windows.Data
  • System.Windows.Documents
  • System.Windows.Forms.Integration
  • System.Windows.Ink
  • System.Windows.Input
  • System.Windows.Media
  • System.Windows.Media.Animation
  • System.Windows.Media.Effects
  • System.Windows.Media.Imaging
  • System.Windows.Media.Media3D
  • System.Windows.Media.TextFormatting
  • System.Windows.Navigation
  • System.Windows.Shapes
  • System.Windows.Shell

As you might (or might not) know, there are other XML namespaces that you can use, each represents a particular version of WPF as follows (to date):

Note that these are all mapped to the same WPF assemblies, though they implicitly define which version of WPF you are targeting.

Also, a note about winfx vs netfx:  winfx was the original name that was used to refer to the W*F technologies (WCF,WPF,WF)… this was later ditched by Microsoft.

Where is XamlPad? How can I download it?


If any of you are like me, you may have read some book, or some blog, that refers to a seemingly obscure little utility called XamlPad.

I read that this was included with the .NET Framework 3.0 SDK… so, I searched high and low… but XamlPad continued to elude me.

Further research showed that XamlPad is no more, surprisingly (or not*) due to Microsoft having a lack of resources.

There are though a few alternatives running around in the wild:

  • XamlPadX – created by a WPF team member (Lester Lobo) and full of bells and whistles ->fetch
  • XAML Cruncher – a ClickOnce application (neat), created by Charles Petzold (haven’t heard of him? Shame on you!) ->fetch
  • Kaxaml – Robby Ingebretsen’s offering (ex WPF team member) ->fetch

* well, I say ‘or not’ here since even if Microsoft do have LOTS of developers, they are also pretty busy nowadays, so I am not surprised that a teeny tool like this would be pushed aside, considering that there are comparable maintained tools out on the market already.