none
Why INotifyPropertyChanged and Binding both?

    Question

  • I have two fields FirstName and LastName bound to two TextControl in a two way binding. I have a third control FullName bound to a FullName field which is FirstName + LastName. This is a oneway binding. The expected result is whenever I changed focus from FirstName or LastName controls, the FullName control should reflect the change.

    My understanding of the Binding is that whenever the property that is bound to the control changes, the UI will be reflected with the change. However it does not work in my case.

    I have to implement a INotifyPropertyChanged interface and raise that event when the FullName field changes if I have to see the change in the FullName control. Why is it so? Why the Binding can't detect the property change in the field FullName and reflect that change on the UI?

     

    Monday, April 30, 2012 8:47 AM

Answers

  • But my question is why the notification has to be raised. Doen't <TextBlock Text="{Binding FullName}" /> tell that the textbox is bound to FullName and the control can be changed when the property FullName is changed like in the code below.

    How do you want that the control knows that, when you change the FirstName property, the FullName property also changes?

    The binding is here to indicate that, when the value changes, the change must me propagated to the other side of the binding. The INotifyPropertyChange is here to indicate that the value has changed.

    Note that you must also notify when FirstName and LastName changes. Otherwise, a change of these properties in code behind will not be reflected in the UI.

    Patrick

    Tuesday, May 01, 2012 2:17 AM
  • Here is my understanding on the topic:

    1. At the level of a visual element, say a textbox, it needs to know the container(binding object) from which it has to bring the data.

    It also needs to know what it has to do on the change (specified by the binding Mode). So, initially, the control sets up an associatin (binding) with this object and behaves (Mode) accordingly on changes in data, (ONLY) WHENEVER IT COMES TO KNOW THAT THERE HAS BEEN A CHANGE.

    2. The object, which is the most basic element in itself, contains the data. Being a basic thing, it does not have any thing inbuilt to register the changes to the ui elements. So, it requires a broadcast from the setter method about the change.

    3. The event is a channel of communication between the ui element and the entity. It takes the change notification from the object and broadcasts it to those ui elements which are bound to it. Then it depends on the ui element how to respond to the change. Therefore, on the part of ui elements, we need to specify the Binding and Mode, and still need to raise the event on the data side.

    Tuesday, May 01, 2012 1:27 PM

All replies

  • Try next:

    <StackPanel Orientation="Vertical">
        <TextBox Text="{Binding FirstName, Mode=TwoWay}" />
        <TextBox Text="{Binding LastName, Mode=TwoWay}" />
        <TextBlock Text="{Binding FullName}" />
    </StackPanel>

     

    public class MainViewModel : INotifyPropertyChanged
    {
        private string firstName;
        private string lastName;
    
        public string FirstName
        {
            get { return firstName; }
            set
            {
                if (firstName != value)
                {
                    firstName = value;
    
                    RaisePropertyChanged("FirstName");
                    RaisePropertyChanged("FullName");
                }
            }
        }
    
        public string LastName
        {
            get { return lastName; }
            set
            {
                if (lastName != value)
                {
                    lastName = value;
    
                    RaisePropertyChanged("LastName");
                    RaisePropertyChanged("FullName");
                }
            }
        }
    
        public string FullName
        {
            get { return String.Format("{0} {1}", FirstName, LastName); }
        }
    
        #region Implementation of INotifyPropertyChanged
    
        public event PropertyChangedEventHandler PropertyChanged;
    
        protected virtual void RaisePropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    
        #endregion
    }
    Monday, April 30, 2012 4:56 PM
  • Thanks for that code. It is okay to me.

    But my question is why the notification has to be raised. Doen't <TextBlock Text="{Binding FullName}" /> tell that the textbox is bound to FullName and the control can be changed when the property FullName is changed like in the code below:

    public string FirstName
        {
            get { return firstName; }
            set
            {
                if (firstName != value)
                {
                    firstName = value;

                    FullName = FirstName + LastName;

                }
            }
        }

    Monday, April 30, 2012 8:14 PM
  • why the notification has to be raised

    because no magic Smile... Hope this helps:

    http://kindofmagic.codeplex.com/

    Tuesday, May 01, 2012 2:02 AM
  • I have to implement a INotifyPropertyChanged interface and raise that event when the FullName field changes if I have to see the change in the FullName control. Why is it so? Why the Binding can't detect the property change in the field FullName and reflect that change on the UI?

    This is by design and my understanding is that it also provides programmer an option that when value changed on back end but don't want them to reflect on UI.

    Tuesday, May 01, 2012 2:10 AM
  • But my question is why the notification has to be raised. Doen't <TextBlock Text="{Binding FullName}" /> tell that the textbox is bound to FullName and the control can be changed when the property FullName is changed like in the code below.

    How do you want that the control knows that, when you change the FirstName property, the FullName property also changes?

    The binding is here to indicate that, when the value changes, the change must me propagated to the other side of the binding. The INotifyPropertyChange is here to indicate that the value has changed.

    Note that you must also notify when FirstName and LastName changes. Otherwise, a change of these properties in code behind will not be reflected in the UI.

    Patrick

    Tuesday, May 01, 2012 2:17 AM
  • Here is my understanding on the topic:

    1. At the level of a visual element, say a textbox, it needs to know the container(binding object) from which it has to bring the data.

    It also needs to know what it has to do on the change (specified by the binding Mode). So, initially, the control sets up an associatin (binding) with this object and behaves (Mode) accordingly on changes in data, (ONLY) WHENEVER IT COMES TO KNOW THAT THERE HAS BEEN A CHANGE.

    2. The object, which is the most basic element in itself, contains the data. Being a basic thing, it does not have any thing inbuilt to register the changes to the ui elements. So, it requires a broadcast from the setter method about the change.

    3. The event is a channel of communication between the ui element and the entity. It takes the change notification from the object and broadcasts it to those ui elements which are bound to it. Then it depends on the ui element how to respond to the change. Therefore, on the part of ui elements, we need to specify the Binding and Mode, and still need to raise the event on the data side.

    Tuesday, May 01, 2012 1:27 PM
  • Thank you guys for the response. I was able to see the response only today.

    As I understand this now, the notification is equivalent to writing txtFullName.Text = "John Doe" in a windows application. Since the control is already bound and no control id is available to change the content via code behind, the notification is the only way to make the update. The other intention is also to avoid the code behind and do it via View Model directly.

     

    Thursday, May 10, 2012 8:20 AM