none
Frame.Content`s DataContext is not inheritted from the Frame

    Question

  • I have a Frame in a DataTemplate and load its content through Source property from external XAML which has a StackPanel as a root element.

    DataContext of the StackPanel is null and not set to Frame.DataContext.

    Should not the DataContext be inherited from parent?

    Is it by design or a bug of ContentControl?

    Anyway this is a workaround:

    public class FrameEx : Frame

    {

    protected override void OnContentChanged(object oldContent, object newContent)

    {

    if (newContent is FrameworkElement)

    {

    (newContent as FrameworkElement).DataContext = this.DataContext;

    }

    base.OnContentChanged(oldContent, newContent);

    }

    }

    Wednesday, January 24, 2007 2:03 PM

All replies

  • As the frame can host objects outside of the scope of your application or control, I don't think it should. Inherited dependency properties stop at the frame/page transition, and as a matter of fact at the usercontrol level (which imo is definitly a limitation).
    Wednesday, January 24, 2007 8:04 PM
  • You will probably find other issues with using Frame in that capacity.

    For instance, Frame has internal behavior whereby it will replace the apparent source of any event that bubbles through it, with source reported as Frame.

    Frame is intended as a navigation control that contains potentially unvalidated content. If you're already subclassing to get around, a more legitimate subclassing would be to something that has a desirable content model and doesn't deliberately compromise the logical tree below itself. Then just add your own Source property that calls XamlReader.Load from the supplied path and sets the object results to the relevant content property of the base class you chose.

    Thursday, January 25, 2007 2:17 AM
  • Wouldn't you end up with the same bug with journaling, non unique PersistId as is the case with UserControl? This can cause countless issues with navigation.
    Thursday, January 25, 2007 2:28 AM
  • If navigation is part of the requirement, yes you're right. You'd lose something going to another control (in particular the built in commanding, and journaling Source). But I am guessing that navigation & journaling was not really a key part of the original poster's scenario, and more it was the temptation of an easily accessible "Load Me" property.

     

    Thursday, January 25, 2007 2:40 AM
  • I use the frame in data template so no problems with navigation etc.

    It is just "external XAML data template".

    Thursday, January 25, 2007 5:59 AM
  • To answer your question, the default behavior of the Frame class to block property value inheritance of all inheritable properties (not just DataContext) is by design. To make the dividing line between frame and content even clearer, input events won't route through it either. If that weren't the design, there would be far too many thorny issues around frame-hosting XAML content that is not necessarily under your control. Or, with being  hosted by someone else's Frame.

    Your workaround will probably work, but I'd think you'd want to be careful where you put that control, and who you'd let use it.

    Monday, January 29, 2007 11:35 PM
  • Wolf,

    This is a poor design choice and completely forgets about templates.  Even though logically a frame control hosts data from a number of sources, visually a frame control can have several components that still want to be attached to the parent.  The most obvious example would be a TreeView navigation control (usually found on the left side of the page design, as in Windows Explorer).  This TreeView would be used to communicate with the Navigator and drive the content into the PART_NavWinCP.  This design choice has also broken (apparently) any data binding from the controls in a Frame template to the parent controls.

    FWIW,

    Donald Roy Airey

    Friday, June 18, 2010 2:08 PM
  • Is it possible to reenable property value inheritance in Frame?
    Wednesday, September 22, 2010 7:56 AM