none
PropertyChangedEventHandler handler = this.PropertyChanged;

    Question

  • Ah yes the INotifyProperty interface defines the event in title of this post.   A well known pattern often is seen on the internet in using this Interface.  Josh Smith includes this pattern in his ViewModelAbstractBase class as shown here:

    Implementation of INotifyProperyChanged in ViewModel Abstract Base Class
        #region INotifyPropertyChanged Members
            /// <summary>
            /// Raised when a property on this object has a new value.
            /// </summary>
            public event PropertyChangedEventHandler PropertyChanged;
            /// <summary>
            /// Raises this object's PropertyChanged event.
            /// </summary>
            /// <param name="propertyName">The property that has a new value.</param>
            protected virtual void OnPropertyChanged(string propertyName)
            {
                this.VerifyPropertyName(propertyName);
     
                PropertyChangedEventHandler handler = this.PropertyChanged;
                if (handler != null)
                {
                    var e = new PropertyChangedEventArgs(propertyName);
                    handler(this, e);
                }
            }
            #endregion // INotifyPropertyChanged Members

    My question is this: When would and what would cause the handler to be null?


    Javaman
    Thursday, August 26, 2010 5:43 PM

Answers

  • Yes, you are correct that Binding exceptions don't appear as unhandled exceptions. If you watch the output window in visual studio while running your app, you'll notice binding exceptions will pop up there.

    If you want to do something with those exceptions outside the debugger check out this link:

     

    http://blogs.msdn.com/b/mikehillberg/archive/2006/09/14/wpftracesources.aspx

    • Marked as answer by Mr. Javaman Friday, August 27, 2010 6:48 PM
    Friday, August 27, 2010 2:48 PM

All replies

  • It will be null if nobody is subscribed to listen to the event. I.e. if the object isn't bound to anything. Where you'd usually see this cause a problem is if you create and object in code, set some properties and then bind it. When you first set those properties, there is nothing subscribed to the PropertyChanged handler.
    Thursday, August 26, 2010 6:10 PM
  • Thanks, the funny thing is I didn't even think about that...  But then again maybe it's not so obvious in the ViewModel pattern. 

    In the Viewmodel if there are getter and setter properties and the ViewModel implements the InotifyPropertyChanged interface, the only Binding mechanism would be either from the View's datacontext to the ViewModel or a bootstrapper inplicitly setting it.  In the absence of a Bootstrapper, we see a potential problem not knowing why a {Binding path=somepath} statement doesn't bind... I've read somewhere that Binding errors are swallowed by WPF binding system and that there is a way to view the logs.

    So in essence, we are working blindly as WPF is set up to operate now, this makes debugging XAML binding issues tough for me to figure out...  Do you know of how to view the binding logs? 

     


    Javaman
    Friday, August 27, 2010 12:42 AM
  • Yes, you are correct that Binding exceptions don't appear as unhandled exceptions. If you watch the output window in visual studio while running your app, you'll notice binding exceptions will pop up there.

    If you want to do something with those exceptions outside the debugger check out this link:

     

    http://blogs.msdn.com/b/mikehillberg/archive/2006/09/14/wpftracesources.aspx

    • Marked as answer by Mr. Javaman Friday, August 27, 2010 6:48 PM
    Friday, August 27, 2010 2:48 PM
  • Hey Jousts, thanks again for that tip, I didn't realize the output window showed this...  You've helped me to go one step deeper into the magical world of WPF binding. "If it were a snake it would have bit me." 
    Javaman
    Friday, August 27, 2010 6:48 PM
  • Ran some more tests today and proved a few things.

    1) The WPF Binding system is only put into place once the View with the Bindings is shown.  Not when it's instanciated. 

    2) If you'd like, you can put the Binding into the ViewModel like this:  Assume you have a Shell with a Navigator and a Presenter.  The VM exposes both publically but initializes the defaults.  It then news-up the Shell and sets the datacontext.  When the Show happens that's when the Getters are called.  To me this is a more logical place to do this than in the App.cs because it's one time one place, in a more logical place.

    public class ShellVM : ViewModelBase
        {
            private UserControl _navigator;  
            private UserControl _presentation;  
            public ShellVM()
            {
                _navigator = new View.MainNavigator();
                _presentation = new View.MainPresentation();
                MainShell shell = new MainShell();
                shell.DataContext = this;
                shell.Show();
                InitLocal();
            }

     

    Next step, how to maintain global visiblity to the Shell for other Navigators and Presenters.

    Any suggestions?


    Javaman
    Friday, August 27, 2010 11:02 PM