WPF Getting Control null reference during InitializeComponent

Question

So my InitializeComponent method call in the Window\'s constructor is running through the XML and adding the controls and plugging them into their events.

Answer 1

I had the same issue and i think it's a bug. I found a workaround though : I removed the 'Ischecked' from Xaml and set it in the code behind after the init

Answer 2

It was the Checked event on a radiobutton. When i removed Checked="true" from the xaml the issue went away. (though it is checked when the Window starts). Not sure what's going on here, but at least I didn't have to change anything major to fix it... yet.

Answer 3

Are any of the controls using two-way databinding? I've run into this issue where I've had textboxes bound to a properties on a ViewModel. The ViewModel initialization was triggering INotifyPropertyChanged up to the bound control, which in turn caused the textbox's TextChanged event to fire. My short-term workaround was to move the event subscription to the window Loaded event, but like you state, that's kind of a pain. I need to refactor the code to change the order in how my objects get initialized, so that the WPF Views (i.e. windows and user controls) are created before the ViewModels. Then I'll be able to move the event handler registration back into XAML.

Answer 4

I just had this issue too, and solved it by wrapping the line accessing the null control in a null check. This seems like a bit of a hack workaround.

I think WPF is trying to be helpful here by calling our Checked event during InitializeComponent(), in an effort to ensure that any UI logic (e.g. showing/hiding related components) is executed based on the initial state of the checkbox. I tested having the Checkbox unchecked by default, and the event handler is not called, even though I have it wired to both the Checked and Unchecked events. I even reproduced this in a blank WPF project with a single Checkbox on the screen, and it behaves the same.

The problem with this default behavior is obviously that some of the other components are not yet initialized. I think WPF should wait until all the components are initialized before firing the Checked event by default. This might not be considered a bug, but I'm gonna add a note to the relevant MSDN page anyway...

Answer 5

You should be able to check the IsInitialized or IsLoaded properties on your Window to verify it has finished initializing/loading. Otherwise, you would need to check for null or add your event subscriptions in your code behind (after InitializeComponent).

Also, you may be able to adjust how you access the elements. For example, if you have something like:

<ListBox x:Name="listBox" SelectionChanged="OnListBoxSelectionChanged" />

Then in your code behind you can get the list box several ways:

private void OnListBoxSelectionChanged(object sender, SelectionChangedEventArgs e) {
    ListBox lb = this.listBox; // May be null
    ListBox lb = sender as ListBox; // Should never be null
    ListBox lb = e.Source as ListBox; // Same as sender in this case
    ListBox lb = e.OriginalSource as ListBox; // Always the element that started the event (if handler is not attached directly to ListBox).
    // ... Do Something ...
}

Answer 6

The Window Control fires Checked events when initializing sub controls that can be checked and are set to checked as initial value.

I am strongly of the opinion that this is a bug. Just the fact that it fires a NullReferenceException from deep within the MFC assembly should be enough to expect that this is unintended behavior.

Considering that the Xaml editor creates handler functions within your Control partial class and if this class is not finished being constructed it can't handle events. I don't think firing a checked event for a control your setting as initialized to checked seems right at all.

I mean, should it fire an Unchecked event if you set it's initial state to unchecked?