WPF Units and Code-Behind
Asked Answered
G

2

15

Recently I discovered WPF supports different measurement units in XAML. Besides default DIPs, there is also support for pixels, inches and centimeters (as far as I know). This allows designer to write XAML such as this:

<Canvas>
    <Line X1="0cm" X2="3cm" Y1="1cm" Y2="3cm" Stroke="Black"/>
</Canvas>

However, you cannot bind these values. Imagine we have a ViewModel with Dimension property which is a String, for example "7cm". Following won't work:

<Button Width="{Binding Dimension}">Test</Button>

FormatException gets thrown. Similarly, when creating a FrameworkElement in code-behind, like this:

Canvas1.Children.Add(new Button() { Width = "3cm", Content = "Test"});

Compilation fails because exception is thrown in constructor/wherever you try to create the control.

I wonder:

  • Is it possible to use natural units (in my case metric - centimeters) in code-behind?
  • How?
  • Is there a complete list of units WPF/XAML supports?

EDIT:

Here is a link from comment below, which resolves this question:

http://msdn.microsoft.com/en-us/library/system.windows.frameworkelement.width.aspx

Gulgee answered 29/2, 2012 at 18:33 Comment(0)
S
17

You can do this in code behind by applying the same conversion the XAML-parser uses, you do not need to reimplement this logic if you don't mind passing around strings:

button.Width = (double)new LengthConverter().ConvertFrom("2cm");

The XAML-parser uses TypeConverters to convert strings to the needed values, in the documentation page of the Width property you can see that it has a TypeConverterAttribute specifying that a LengthConverter should be used. This attribute can be used to locally override how a property should be handled, but it can also be applied at class level, so if an Employee class has this attribute specifying that an EmployeeConverter should be used said converter will be the default for properties of type Employee.

I am a bit surprised the binding does not apply this type converter, but using it inside an IValueConverter would be simple enough, in fact you could create a markup extension which constructs an IValueConverter from a type converter to make it nicely generic.

Shotputter answered 1/3, 2012 at 0:18 Comment(0)
B
2

For 1) and 2) Because DIPs are device independent, you can calculate any "natural unit" to and from without problems. The exception are (unnatural :) device dependent pixels.

Create a ValueConverter that converts string values to doubles where your desired units may be specified in the string. Then you can use the ValueConverter in your Binding and calculate in your ViewModel in "natural units".

For 3) and the implementation: I have quickly googled and found nothing, but maybe will a deeper search show something. Otherwise, creating your own converter should not be very difficult. Here some conversion infos:

96DIP == 1inch == 2.54cm;
1cm == 37.8DIP;
1zoll == 1inch == 2.54cm;
Berkie answered 29/2, 2012 at 18:43 Comment(6)
I tought Converter could be a way to go. But before I write my very own, do you think there is a way to determite what Converter does XAML parser use? I think there must be a built-in converter in WPF already, since XAML supports this units. So I'd preffer using the built-in one, I just can't figure out a way of determining which one it is. Some stack trace investigation probably? I don't really know, any ideas, please? :)Gulgee
@Aaron: I also like to use existing elements, however for each converter I asked google, I have quickly found the class name. But in this specific case, google had nothing to tell. For detecting the used converter in wpf, I can not help. I never diged deeper into the FCL. Maybe this is worth a dedicated question: How to trace which ValueConverter is used by WPF for a specific conversion?Berkie
Thanks for your answer. I'll try to figure a right Converter on my own and possibly ask a new question if I fail. Thanks again!Gulgee
Aha! msdn.microsoft.com/en-us/library/…Gulgee
@HCL: You might be interested in my answerShotputter
@H.B. Thanks for your comment and +1 for your answer (and also for the comment): It's good to know.Berkie

© 2022 - 2024 — McMap. All rights reserved.