Archive

I’m always finding that I need to get a reference to the root element (this) in my XAML markup. If I’m in a situation that I can use a Binding, I can do something like this where I’m getting the Height of the current Window):

However, there are many times that I need a reference to the root where I can’t use a binding. I really, really hope somebody will prove me wrong and show me there is a better way to do this that’s already built in to WPF, but since I haven’t been able to find anything, I added a MarkupExtension that uses reflection to get a reference to the private fields serviceProvider._Context._rootElement:

Yes, this is a terrible hack using reflection to access private fields, and there’s a good chance it will go away in a future version of WPF…hopefully because Microsoft builds in their own extension to do this properly. If you know of a better way, please speak up!

[Update: Microsoft addressed this is .NET 4]

Here is a new version that doesn’t require reflection using the updated API in .NET 4:

Reflection is a very powerful tool for building code that is highly customizable at runtime, making it very reusable. If you’re going to make an application that is primarily loose XAML, you will want to make whatever code you do write as flexible as possible, and to do so, it helps to have a firm grasp of reflection.

With WPF, it is very simple follow the MVC pattern where a CLR object or XML is acting as your Model, and you want to present the data from the Model in a View, which is built in XAML by binding WPF controls to elements in the Model. What happens when we want to make changes to the data in the Model, such as updating some properties of that object? Your user is interacting with the View, so you need something in between the View and the Model, which is your Controller.

The most common approach to updating the data is to write event handlers in the code behind for your XAML file (your View). However, this means that your Controller logic is tightly coupled with your View…you can’t easily reuse it in another View. If you implement your Controller logic as a WPF ICommand, you can keep the logic in a different class and use it declaratively from any XAML file.