44

I have the following (abbreviated) xaml:

<TextBlock Text="{Binding Path=statusMsg, UpdateSourceTrigger=PropertyChanged}"/>

I have a singleton class:

public class StatusMessage : INotifyPropertyChanged
{   
    private static StatusMessage instance = new StatusMessage();

    private StatusMessage() { }

    public static StatusMessage GetInstance()
    {
        return instance;
    }

    public event PropertyChangedEventHandler PropertyChanged;
    private void OnPropertyChanged(string status)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(status));
        }
    }

    private string statusMessage;
    public string statusMsg
    {
        get
        {
            return statusMessage;
        }
        set
        {
            statusMessage = value;
            OnPropertyChanged("statusMsg");
        }
    }
}

And in my main window constructor:

StatusMessage testMessage = StatusMessage.GetInstance();
testMessage.statusMsg = "This is a test msg";    

I cannot get the textblock to display the test message. When I monitor the code through debug, the PropertyChanged is always null. Any ideas?

abatishchev
  • 98,240
  • 88
  • 296
  • 433
Dave
  • 1,065
  • 2
  • 10
  • 16

11 Answers11

21

Thanks Jerome! Once I set the DataContext it started working as it should! I added the following to the main window constructor for testing purposes:

 this.DataContext = testMessage;
Dave
  • 1,065
  • 2
  • 10
  • 16
16

I ran into this today and wasted some time on it, and eventually figured it out. I hope this helps save you and others some time.

If there are no subscribers to your event, and you simply declared the events as:

public event EventHandler SomeEventHappened;

Then null reference is expected. The way around this is to declare as follows:

public event EventHandler SomeEventHappened = delegate { };

This will ensure that it is not a null reference when you call as

SomeEventHappened()

Another pattern i've seen is to not initialize to delegate {} and instead check for null:

var eventToRaise = SomeEventHappened;
if( eventToRaise != null )
{
    SomeEventHappened()
}
danielpops
  • 713
  • 6
  • 13
  • 1
    The reason that setting `this.DataContext = testMessage;` makes it work is that per my answer, that effictively establishes a subscription the the event that you wish to fire, hence it is no longer null. – danielpops Mar 31 '11 at 17:52
  • 3
    I believe that the "check for null" approach is now the preferred approach. I did try initializing the event handler as you did in your first case and, true, the event was no longer null but the INotifyPropertyChanged event didn't trigger an update to the List I was using. The fix was to use INotifyCollectionChanged (see: https://stackoverflow.com/questions/37329991/propertychanged-event-handler-always-null-in-win-phone-8-application for my experience with this problem). – rfreytag May 24 '16 at 14:18
9

Your OnPropertyChanged string must exactly match the name of the property as it's case sensitive.

Try changing

OnPropertyChanged("StatusMsg");

to

OnPropertyChanged("statusMsg");

Update: Also - just noticed that you're binding to StatusMsg (capital 'S'); so the control was not binding to the property, which is another reason why it wasn't updating!

Matt Davis
  • 45,297
  • 16
  • 93
  • 124
kiwipom
  • 7,639
  • 37
  • 37
  • I made the 2 changes as you suggested Ian, PropertyChanged is still evaluating as NULL. Kinda odd, I know this should work! I edited the code to reflect the changes. – Dave Oct 03 '09 at 03:36
  • 3
    @IanR i don't think it would be null , because of that, it just wouldn't update the property he states that it doesn't even get a chance to update since it's null – eran otzap Feb 28 '12 at 16:00
5

Just in case: I had a similar problem but my mistake was that class which implemented INotifyPropertyChanged was private. Making it public resolved my case.

komizo
  • 1,052
  • 14
  • 21
4

in my case this make it to work:

public partial class MainWindow : Window, INotifyPropertyChanged
{
    public MainWindow()
    {
        InitializeComponent();
        this.DataContext = this;    // this row fixed everything
    }
    ****
    Some code here with properties etc
    ***
}
saha0404
  • 41
  • 1
1

Another point - for PropertyChanged to be null make sure you bind the object to the DataContext and then set the Path instead of directly assigning the property to the UI field.

1

I also have seen the PropertyChanged event be null when I have existing data assigned to the control's data bound property:

<TextBlock Name="CarTireStatus" Text="{Binding TireStatus}" >Bad Text!</TextBlock>

Where as this works:

<TextBlock Name="CarTireStatus" Text="{Binding TireStatus}" ></TextBlock>
OutThere
  • 11
  • 2
0

There is a couple of items to check for when observing the PropertyChanged event object as null.

  1. Ensure the property name passed in as an argument when raising the event actually matches the name of the property you are targeting.

  2. Ensure that you are using only one instance of the object that contains the property you are binding to.

For item number two, this can be done by simply placing a break point on the class constructor for the object that harbors the property that is being bound. If the breakpoint is triggered more than once, then you have a problem and need to resolve the number of instances of objects to only one instance that your runtime invokes via XAML.

Thus, it's better to implement that class as a singleton pattern so that you can ensure just one instance of the object at runt-time.

Scott Nimrod
  • 11,206
  • 11
  • 54
  • 118
  • 3
    What, Singleton? What?! Never read so much rubbish in my life. The binding system will subscribe to the correct instance's event. If not WPF would just not work. Consult any beginners MVVM article for a working best-practice demonstration of how wrong you are. – Gusdor Feb 02 '11 at 16:35
  • This is speaking from my own experience from trouble-shooting. I had more than one instance of my view model at run-time. Thus, this update worked for me. Thanks for your input though. – Scott Nimrod Feb 16 '11 at 14:30
  • Also, ensure that all the data is loaded (i.e. Loaded event). – Scott Nimrod Mar 10 '11 at 12:39
  • I think Scott and Gusdor are talking about different staff. Scott is talking about the the ViewModel, which indeed should be the same all the time, while Gusdor is talking about the Model, which surely can be any number of objects. Scott indeed inspired me on debugging a similar situation. Thanks. – lznt Aug 13 '15 at 18:57
0

To complete the story, I also find if the bound property is static and the PropertyChanged event is not static, it will be null. A simple fix is to declare another static event so you have both as below:

public event PropertyChangedEventHandler PropertyChanged;
public static event PropertyChangedEventHandler StaticPropertyChanged;

Call PropertyChanged?.Invoke() or StaticPropertyChanged?.Invoke() according to whether the target property is static.

Carl Chang
  • 119
  • 5
-1

I had a similar issue, neither solutions above helped me. All I needed to do was to use the built c# Propertychanged. Beforehand I have implemented propertyChanged (by an accident) and it pointed at nothing.

DGR
  • 422
  • 1
  • 4
  • 14
-3

If you follow all instructions, verifying your property name is correct, that it is correctly being assigned a new value, you are using a singleton to guarantee one instance of you view model, and you have successfully assigned your DataContext in the UI - make sure that whatever is forcing your property to update is done after the visual tree has been completed, i.e. move the refresh of your property to a button, rather than say the Loaded event of your window. I say this because I had the same issue, and found that when I refreshed my view model data property from my Infragistics NetAdvantage ribbon window's Loaded event, my PropertyChanged event was always null.

jadusty
  • 935
  • 5
  • 7
  • This answer has terrible grammar and does not offer a structured answer. You are proposing that the person monitor from the view loading, which is complex and will likely confuse them even more. If this is really your method of troubleshooting a null Prop event handler, you should provide methodology not an example of you doing it. – N_tro_P Oct 11 '17 at 13:42