title: Detecting DataContext changed in Silverlight
body: <p>I have a multi-part question:</p>
  
  <p>(1) Is there a good reason why Silverlight doesn't expose a DataContextChanged event?  It seems like a whole lot of hassle could be avoided if someone at Microsoft just changed <code>internal</code> to <code>public</code> in the FrameworkElement class (like WPF does).</p>
  
  <p>(2) I've found <a href="http://www.codeproject.com/Articles/38559/Silverlight-DataContext-Changed-Event.aspx">one</a> or <a href="http://www.pochet.net/blog/2010/06/16/silverlight-datacontext-changed-event-and-trigger/">two</a> different methods for hacking your way into a DataContextChanged event by using DependencyProperties in one configuration or another.  But I can't get them to work reliably.  My testing so far seems to show that they fire the hacked DataContextChanged event just fine for the first class to which I hook them up, but don't fire for any other classes.  Has anybody else run into that problem? Or better yet, have they worked their way around it?</p>
  
  <p>(3) The reason I've been giving myself for wanting to know when my DataContext has changed is that there are some UI operations that are complicated to get right in XAML, but are trivial in code-behind; and for many of those things, I need to handle events raised by my ViewModel; and hence I need to know when my ViewModel has changed, so I can wire up the event handlers. Is this an accurate view of the world? Or is the fact that I'm wanting to deal with this sort of thing in code-behind a pretty good indication that my thinking has gone off the rails some ways back? I'm no MVVM purist: I just want to get from here to good code quickly, and I don't particularly care how I get there. Code-behind has served me reasonably well for over a decade now, and I'm loth to abandon it entirely.  But is my pragmatism making it harder on myself at this point?</p>