Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
Does XamDataChart support ItemsSources that implement ITypedList?

I'd like to display data in a chart, where I do not know at compile time the name of the property that I need to bind my data series too.

I have a collection class that implements ITypedList and INotifyCollectionChanged. I've tried having it implement IList and IEnumerable and IBindingList. I've also tried making it a subclass of ObservableCollection, but no luck -- meaning, the chart never displays any data. It also never calls any of the ITypedList methods (by setting breakpoints in the debugger).

However, for one specific test case (where I do know the names of the x,y properties at compile time), I create a special "holder" class with these properties defined at compile time. In this case, the chart displays the data.

So, does XamDataChart honor ITypedList? Is there an example floating around? Or do you suspect I must be doing something wrong somewhere? THanks!

  • 30692
    Verified Answer
    Offline posted


    There is no explicit support for ITypedList, it supports properties or IDictionary (string indexers). If you have a string indexer on your objects or interface, you should be able to use that through square brackets in the member path. Other than that you would need to make a feature request.

    You could also get a bit fancy and dynamically create a type that has clr properties for the dynamic properties on your items. This link shows how you can achieve this for dynamic objects:

    A similar mechanism would work for ITypedList. There area also various adaptors that would turn an ITypeList into something that implements IDictionary for the items.

    Or you could project the list yourself into a nominal type before sending it to the chart. For example, if you had a type that looked like this:

    public class ChartItem { public string Label { get; set; } public double Value { get; set; } }

    Then you could copy the appropriate properties into that item type while binding, and then you wouldn't need to dynamically adjust the member paths on the axes and the series since they are always expecting the same property names.

    If all this seems to cumbersome though, please do make that feature request so that we can appropriately prioritize our backlog. The above suggestions are basically to give you work arounds so that you aren't blocked by a missing feature.


Reply Children