tags:

views:

495

answers:

2

When designing WPF application UI's in XAML, should every container-type control contain a layout control to house all children controls?

Take a group box, for instance. I can either throw controls onto the group box directly, or I can use a layout control and place the layout control inside of the group box and then controls in that.

I can see the benefit in the latter because the layout control represents a set of well-defined rules for how the children will behave. In doing this, however, my XAML tree starts getting deeply nested and a little harder to navigate.

Given this, is it best practice to always use layout controls or are there cases where it is perfectly acceptable to throw a control inside group boxes and tab items without such? What would be the negative implications of this if any?

+2  A: 

There is no negative implications in using Layout panels because even if you havent specify one, there is a default one in the VisualTree. If you don't use one explicitly, your XAML may looks cleaner.

Most of the ItemsControls have a StackPanel as the default Layout. So it is basically a question of whether you want a StackPanel behavior to arrange your child items or not?

Jobi Joy
+1  A: 

Jobi is correct that there are really no implications either way, but my gut instinct has always been to use a Container to hold multiple controls. A lot of that is driven by my need for highly structured organization, but mostly it just makes sense to me.

I do end up with a lot of nested Grids, StackPanels, etc. Yes, the tree can get pretty deep, but I use Blend almost exclusively for layout and design, so navigating the tree is not so bad, especially if you remember to give everything good descriptive names.

I don't know if it's "Best Practice" but it certainly works best for me.

Joel Cochran