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:

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

Hope it helps :)


Method not found: ‘Boolean MS.Internal.AssemblyHelper. IsXLinqNonIdempotentProperty’

If you are using .NET 4, and run into this exception:

Method not found: ‘Boolean MS.Internal.AssemblyHelper.IsXLinqNonIdempotentProperty’

Then it turns out that there is actually a bug in .NET 4, which seems to occur when you apply a ScaleTransform to an element that has nested templates (which is almost always the case in most LOB applications).

Turns out that the good folks at Microsoft have addressed this issue in December 2010, by releasing patch number KB2464222 which you can grab here :)

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.