Home Dashboard Directory Help
Search

ContentPresenter's DataContext should use its inherited DataContext and not use its own Content by krispenner


Status: 

Closed
 as Won't Fix Help for as Won't Fix


7
0
Sign in
to vote
Type: Bug
ID: 596674
Opened: 9/9/2010 7:27:41 PM
Access Restriction: Public
1
Workaround(s)
view
4
User(s) can reproduce this bug

Description

ContentPresenter cannot bind to its inherited data context, instead all binding is against its Content property. This I would imagine is wrong, it does not follow how every other control's data context works.


Thanks,
kp
Details
Sign in to post a comment.
Posted by Microsoft on 7/3/2013 at 8:27 AM
Thanks for your feedback!

We have reviewed this issue, and unfortunately are not able to address it in the currently released version of Silverlight.

Thanks,
Silverlight team
Posted by Andrew S on 1/10/2013 at 7:45 AM
I'm surprised MS didn't close this. The ContentPresenter has always worked this way. It sets its own DataContext to the Content because the things within its ContentTemplate need to get access to the object that it is representing. This isn't ideal but I don't see how MS could change this at this point.
Posted by MickleKulls on 2/22/2012 at 4:12 PM
I have the same issue except mine is much simpler. I just have a tooltip and using it like this

<TextBlock.ToolTip>
    <ContentPresenter Content="{Binding Path=StaffClashes}" ContentTemplate="{StaticResource clashesGridTemplate}" />
</TextBlock.ToolTip>

This fails where it works with other controls. StaffClashes is a collection so maybe that is part of the issue. As SoldSource said, changing to a label fixes it.
Posted by SolidSource on 10/18/2011 at 4:29 AM
I encountered this problem in a different context and solved it by using a Label instead of a ContentPresenter.
Posted by Michael Lemley on 9/16/2010 at 3:35 PM
We have a control derived from ContentControl and would like to have the Content use binding statements to get values from the contained control.

I expected this to work:

        <ContentControl Background="Green" >
            <ContentControl.Content>
                <Border BorderThickness="1" BorderBrush="Black">
                    <StackPanel>
                        <Rectangle Width="20" Height="20" Fill="Red"/>
                        <Rectangle Width="20" Height="20" Fill="{Binding Background}"/>
                    </StackPanel>
                </Border>
            </ContentControl.Content>
            <ContentControl.Template>
                <ControlTemplate TargetType="ContentControl" >
                    <StackPanel >
                        <ContentPresenter x:Name="contentPresenter" DataContext="{Binding RelativeSource={RelativeSource TemplatedParent}}"/>
                    </StackPanel>
                </ControlTemplate>
            </ContentControl.Template>
        </ContentControl>

Unfortunately, the Fill property binding statement in the lower rectangle (of ContentControl.Content) doesn't resolve.

The only workaround I could find for both WPF and Silverlight is ElementName binding.
WPF has the option of using FindAncestor (see http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/ec438c85-d821-464b-9aab-17cb6fd81af2/). However, in Silverlight doesn't support FindAncestor yet.

ElementName binding isn't as clean as DataContext because it requires keeping the name of the control in sync with the content's binding statement. Additionally, ElementName binding will not work for setting the Content in a style.

Is there another workaround for Silverlight and WPF other than ElementName binding?
Posted by Microsoft on 9/10/2010 at 1:44 AM
Thanks for your feedback. We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Sign in to post a workaround.
Posted by MickleKulls on 2/22/2012 at 4:13 PM
Changing to a label as suggested by SolidSource fixes the issue so I would say it is definately a bug.
File Name Submitted By Submitted On File Size  
SL4Bug.zip 9/9/2010 73 KB
SL4Bug.zip 9/9/2010 73 KB