none
CollectionContainer does not support RelativeSource

    Question

  • Hi all

    I've discovered that I cannot assing a relative binding to a CollectionContainer.Collection dependency property:

    Code Snippet

        <ListBox>
          <ListBox.ItemsSource>
            <CompositeCollection>

    // binding works

              <TextBox Text="{Binding RelativeSource={RelativeSource AncestorType=local:Window1},Path=Number2,Mode=OneWay}"/>

    // binding fails ("cannot find source ...")

              <CollectionContainer Collection="{Binding RelativeSource={RelativeSource AncestorType=local:Window1},Path=Numbers3,Mode=OneWay}"/>
            </CompositeCollection>
          </ListBox.ItemsSource>
        </ListBox>



    I guess that this behaviour is because CollectionContainer does not derive from FrameworkElement, therefore the CollectionContainer not being part of the visual tree.

    Are there any workarounds, other than writing a Wrapper (which is what I intend to do)?

    Kuno
    Tuesday, August 21, 2007 5:13 PM

Answers

  • You're right on almost all counts.  We should fix this.  I've opened a bug.

     

    The only place I differ with you is whether CollectionContainer should derive from FrameworkElement.  It doesn't need to, provided that the data binding engine can discover its "governing FrameworkElement".  This works for Freezables, for example, which do not derive from FE.  The same mechanism should be applied to CollectionContainer.

     

    Thanks for the report.

     

    Monday, August 27, 2007 10:59 PM

All replies


  • you can set the data context of the list view to

    DataContext = {Binding RelativeSource={RelativeSource AncestorType=local:Window1} }

    and then you binding for CollectionContainer would be

    Collection={Binding Path=Numbers3}

    regards
    Tuesday, August 21, 2007 5:52 PM
  • Unfortunately, this doesn't help. I get the following binding error in the trace log:

     

    System.Windows.Data Error: 2 : Cannot find governing FrameworkElement or FrameworkContentElement for target element. BindingExpressionStick out tongueath=Numbers3; DataItem=null; target element is 'CollectionContainer' (HashCode=59109011); target property is 'Collection' (type 'IEnumerable')

    Wednesday, August 22, 2007 6:51 AM
  • I investigated a bit more. I still have the opinion that CollectionContainer should be derive of FrameworkElement in order for a RelativeSource reference to be applicable.

     

    Writing a CollectionContainerEx (deriving of FrameworkElement) with an implicit conversion operator to CollectionContainer doesn't help, since the CompositeCollection tests explicitly ("is" keyword) for CollectionContainer. The conversion operator never gets invoked.

     

    Writing a CompositeCollectionEx and overriding the "public new int Insert(object o)" method does not help either, since the call is not virtual.

     

    I don't see any possiblity in using attached properties either.

     

    My conclusion is that I cannot use declarative data binding for this problem. I'll have to resort to explicitly assigning the collection at runtime.

     

    Kuno

    Wednesday, August 22, 2007 8:21 AM
  • You're right on almost all counts.  We should fix this.  I've opened a bug.

     

    The only place I differ with you is whether CollectionContainer should derive from FrameworkElement.  It doesn't need to, provided that the data binding engine can discover its "governing FrameworkElement".  This works for Freezables, for example, which do not derive from FE.  The same mechanism should be applied to CollectionContainer.

     

    Thanks for the report.

     

    Monday, August 27, 2007 10:59 PM
  • Was this bug fixed in .NET 3.5 Service Pack 1 ?
    Monday, August 25, 2008 10:45 AM
  • From the problems I'm just having, I'd ave to say no :(

    This is really a big problem. We can't go around adding strange properties to the inner modl for the sake of databinding, that defeats the whole purpose of WPF.
    And if you try to use an asynchronous binding, creating the collection on demand behind the scenes will not work either, because the containers will have been created on another thread and you'll get exceptions.



    Denis
    Saturday, August 30, 2008 9:32 PM
  • Right - this bug was not fixed in 3.5sp1.   Still on the radar, though.


    Dev Lead, Windows Presentation Foundation, WinFX
    Wednesday, September 10, 2008 6:43 PM
  • Is there a way to work around?
    Thursday, September 24, 2009 11:31 PM
  • I've also run into the same issue, any chance this will be fixed anytime soon?
    Monday, November 02, 2009 7:23 PM
  • And how about 4.0? Is the bug fixed now?
    Friday, November 20, 2009 8:18 PM
  • @Anton, .NET 4 - not fixed!
    Shimmy
    Monday, December 13, 2010 12:31 AM
  • I was able to do this:

     

            <Grid Style="{StaticResource list_grid_style}">
                <Grid.Resources>
                    <CollectionViewSource Source="{Binding RelativeSource={RelativeSource AncestorType=local:Window1}, Path=Items}" x:Key="items" />
                </Grid.Resources>
                <ListBox>
                    <ListBox.ItemsSource>
                        <CompositeCollection>
                            <TextBlock Text="Categories" />
                            <CollectionContainer Collection="{Binding Source={StaticResource ResourceKey=items}}" />
                        </CompositeCollection>
                    </ListBox.ItemsSource>
                </ListBox>
            </Grid>
    

    I retyped that from my codebase, so I apologize if there are any syntactical errors, but you get the idea. Hope that helps.

    Friday, September 30, 2011 4:37 PM
  • Thanks much!

    This works!

    Friday, January 13, 2012 12:21 PM