In a constructor for a WPF Window, what should go before InitializeComponent() and what after?

Question

In general, I've been initializing the properties of the Window itself before InitializeComponent() and setting up controls contained within afterwards. However, I haven't been all that consistent, and I haven't really noticed a problem with the ordering. So:

• Am I (potentially) doing something horrible? In particular, are there any issues with setting properties of child controls before InitializeComponent()?
• What is good style in this regard?

Edit: Since the first two answers I got were a little bit contradictory, let me be more specific:

public Foo Foo {get; protected set}
public FooWindow (Foo foo)
{
    Foo = foo;
    this.Closing += FooWindow_Closing;
    Foo.Frobbed += Foo_Frobbed;

    InitializeComponent();

    this.DataContext = this;
    this.Title = Foo.Name() + " Window";

    FooListView.ItemSource = Foo.CalculateList();

    FocusManager.SetFocusedElement(this, FooListView);
}

Is this about right? Should I just be doing MVVM and not have anything in my Window constructor?

Answer 1

By calling InitializeComponents after some other code you run the risk of accidentally overwriting properties with things that were set in the XAML or of using an uninitialized object. Usually the code-behind is a higher priority than the XAML so I would leave InitializeComponents (aka, parse and load the XAML) at the top.

Answer 2

In answer to your specific questions:

Am I (potentially) doing something horrible? In particular, are there any issues with setting properties of child controls before InitializeComponent()?

Chances are that your child controls aren't available to you in code yet until you've called InitializeComponents. It would generally be bad form to do this.

What is good style in this regard?

This is going to be a matter of taste, but generally I would recommend that if you're going to take advantage of the separation that XAML affords you then I would take it as far as you can. If you're doing things that are logically about the UI try to do it in XAML. This isn't so much an MVVM thing as it is a separation of presentation from logic. Most of what you have in your sample code can be done declaratively, even if just through ValueConverters.

E.g if Foo was a DependencyProperty then you could also attach it in XAML and add the callbacks as part of the ValueChanged callback. Again, this isn't MVVM, but it is pretty fundamental to WPF.

For most other things, you actually probably want to wait until OnLoaded is called, rather than doing the work in the constructor.

Hope that helps,