best practices for hard-coded sizes in XAML

Question

I'm aware that in WPF you want to keep the sizes of controls as flexible as possible so that they can flow and expand depending on their context (like in CSS).

But most of the code examples I come across are hard-coding sizes like the heights in this example:

<Grid.ColumnDefinitions>
    <ColumnDefinition Width="0.5*"/>
    <ColumnDefinition Width="0.5*"/>
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
    <RowDefinition Height="31"/>
    <RowDefinition Height="31"/>
    <RowDefinition Height="31"/>
</Grid.RowDefinitions>

Isn't assigning a height of "31" to each row a bad practice that should not be emulated? Or is there a reason for this? Or could it be that authors create these examples in design view and just don't clean up the hard coded heights.

Does anyone have any best practices regarding element sizing (especially with respect to using the * syntax) that people starting out with XAML can follow to develop good habits from the beginning?

Answer 1

Generally speaking, it's a best practice to use dinamic sizes within XAML because as you say the concept of WPF is to be indipendent from fixed dimensions. In your particular example, i don't know if it's wanted from the writer, remember that there are still some cases involving hardcoded values (maybe a custom menu bar or a panel you want to keep consistent in it's size). The notation "2*" means that the value will be twice the value of other columns and thus, using the star notation in each column is not very usefull.

If you're looking for some examples, i can address you to these two sites (but if you search on google for "WPF star size" or something like that you'll find others). Plus, if you're looking for a very good book about WPF, I can surely point you to Windows Presentation Foundation by Adam Nathan. It's one of my favourite, it's well written, full of coloured examples and covers every single aspect of WPF.

Answer 2

It is better in most cases to use dynamic sizes except in certain instances as Stefano noted. You should remember that WPF is a fairly new technology and a lot of people are trying to learn it. Usually, when learning a new technology, people will start by making what they know (e.g. write in C# as if it's Java) and then start to write code in the "correct" way only after they have learned a bit. Always take blog posts with a grain of salt.

However, from the code you posted I'm guessing they used Blend to create the XAML. It's always doing silly things like adding row heights and making both columns "0.5*".

Answer 3

Sometimes you can't get away from explicit sizing, expecially when you work with designer assets which are typically converted into sized paths in a tool like Expression Design. When you want to layout a control with explicit sizing and then turn around and work with it like a dynamically sized object, you should use the Viewbox.

In WPF, wrapping up a sized control in a Viewbox will take care of dynamically executing transforms so it will scale properly. This probably has a performance implication but I don't know how much worse it is than dynamically defining sizes. In Silverlight there is no Viewbox out of the box but you can use the Silverlight Toolkit's prototype Viewbox to give you an equivalent experience.