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

Question

In general, I initialized the properties of Window itself to InitializeComponent() and set up the controls contained in the future. However, I was not so consistent, and I did not notice a problem with the order. So:

• Am I (potentially) doing something terrible? In particular, are there any problems with setting properties of child controls prior to InitializeComponent() ?
• What is good in this regard?

Edit: since the first two answers I received were a bit controversial, let me clarify:

 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); } 

It is right? Should I just do MVVM and not have anything in my Window constructor?

Answer 1

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

Answer 2

In response to your specific questions:

Am I (potentially) doing something terrible? In particular, are there any problems with setting properties of child controls prior to InitializeComponent ()?

Most likely, your child controls are not yet available to you in the code until you called InitializeComponents. This would usually be a bad form.

What is good in this regard?

It will be a matter of taste, but as a rule, I would recommend that if you use the section provided by XAML, then I will take it as far as possible. If you are doing something that is logically related to the user interface, try doing it in XAML. This is not so much an MVVM thing, but a separation of a view from logic. Most of what you have in your sample code can be done declaratively, even if only through ValueConverters.

For example, if Foo was a DependencyProperty, you can also add it to XAML and add callbacks as part of the ValueChanged callback. Again, this is not MVVM, but it is quite fundamental to WPF.

For most other things, you probably want to wait while OnLoaded is called, instead of doing work in the constructor.

Hope this helps,

Answer 3

I usually name anything that does not require a Visual Tree before I call InitializeComponent () .

All my implementations use the MVVM pattern, so I prefer my ViewModel instance to be created and populated before the user interface is loaded to the client.

If you always load InitializeComponent () , you run the risk of creating a bad user experience by showing an unvisited view that suddenly refreshes compared to the one that fills when it appears in the view.