When I try to add a LineSeries to the RadCartesianChart.Series collection, I get the following error:
The specified value cannot be assigned to the collection. The following type was expected: "CartesianSeries".
The following is my XAML code:
<
telerik:RadCartesianChart.Series
>
<
telerik:BarSeries
CombineMode
=
"Stack"
CategoryBinding
=
"Region"
ValueBinding
=
"POToSOWeeks"
>
</
telerik:BarSeries
>
<
telerik:BarSeries
CombineMode
=
"Stack"
CategoryBinding
=
"Region"
ValueBinding
=
"SOToWOWeeks"
>
</
telerik:BarSeries
>
<
telerik:BarSeries
CombineMode
=
"Stack"
CategoryBinding
=
"Region"
ValueBinding
=
"WOToKitWeeks"
>
</
telerik:BarSeries
>
<
telerik:BarSeries
CombineMode
=
"Stack"
CategoryBinding
=
"Region"
ValueBinding
=
"KitToShipWeeks"
>
</
telerik:BarSeries
>
<
telerik:BarSeries
CombineMode
=
"Stack"
CategoryBinding
=
"Region"
ValueBinding
=
"KSToKIWeeks"
>
</
telerik:BarSeries
>
<
telerik:BarSeries
CombineMode
=
"Stack"
CategoryBinding
=
"Region"
ValueBinding
=
"KSToCIWeeks"
>
</
telerik:BarSeries
>
<
telerik:LineSeries
Stroke
=
"Red"
StrokeThickness
=
"2"
CategoryBinding
=
"QuarterYear"
ValueBinding
=
"MedianWeeks"
>
<
telerik:LineSeries.HorizontalAxis
>
<
telerik:CategoricalAxis
Visibility
=
"Collapsed"
PlotMode
=
"BetweenTicks"
/>
</
telerik:LineSeries.HorizontalAxis
>
</
telerik:LineSeries
>
</
telerik:RadCartesianChart.Series
>
What am I doing wrong?
8 Answers, 1 is accepted
RadChartView allows you to use different type of Series and Axis. So, you can combine BarSeries and LineSeries.
I trie to follow your code and made sample project (you can find it attached). On my side it works as expected, but I might be missing important part of your implementation. This is why I believe it will be better if you send us a sample project or if you can modify the project I sent. This will allow us to examine your implementation and try to reproduce the issue locally. We can then modify the solution to work per your requirements and send it back to you.
Best regards,
Telerik
Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
Sign up for Free application insights >>
Hello,
I am having the same issue.
Just trying to follow the simple examples in your documentation.
http://www.telerik.com/help/silverlight/radchartview-introduction.html
It doesn't like LineSeries
Please advise on what was found with the previous persons issue with this....
Hello Todd,
I've checked the CategoricaAxisExample and it works as expected without throwing any exceptions. Another example for implementation of the RadCartesianChart with LineSeries you can find in our GitHub Repository - MultipleAxis.
I'm not sure what do you mean with "It doesn't like LineSeries", but you can check which binaries you use in the project - we have two chart controls in two different assemblies. The newer version is RadChartView which requires the Telerik.Windows.Controls.Chart assembly when deploying your application, and the RadChart - Telerik.Windows.Controls.Charting. In the both the class LineSeries exists, so ensure that you have a reference only to the Telerik.Windows.Controls.Chart.dll.
However, there are many details that could affect the series of the RadCartesianChart. Given only the provided information I am not able to track-down the cause of the problem. So, if this information didn't help, please give us more details - a simple project or part of the code would be great.
Regards,
Milena
Telerik
Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
Sign up for Free application insights >>
In my case, I had references to both the Telerik.Windows.Controls.Chart assembly and the Telerik.Windows.Controls.Charting assembly as Milena described above. Once I removed the Telerik.Windows.Controls.Charting reference, I no longer received the error I noted in my original post.
Amy
This whole duplication of names across different namespaces for the same "functionality" (charting) seems poorly thought out. I am having a devil of a time understanding when to use RadChart and whatever other option(s) there is. I would rather you rip out one entire control stack and replace it with new ones. That way, I can easily see what breaks during compilation. Trying to keep the same charts around in different namespaces, some cross-referencing the other, is spaghetti.
The RadChartView is the newer control which addresses some of the limitations and deficiencies that we have identified in the RadChart implementation (we chose to implement a separate control in order not to break backwards compatibility). For detailed comparison between the two controls you can check this help topic.
Generally we would encourage you to use the new RadChartView control for any new project development that you are starting now. As for your existing applications - the migration is possible but there is no straightforward migration path between RadChart and RadChartView due to the different approach taken in the development of RadChartView. However, we focused our efforts on the RadChartView and would strongly recommend using it.
Regards,
Milena
Telerik
Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
Sign up for Free application insights >>
Secondly, the syntax between the two libraries is so completely different that it a a MAJOR undertaking to convert between the two.
Third, the user interaction (or lack thereof) with new charts and elements, the elimination of legends on charts, and several other radical differences have me seriously questioning whether I want to go forward with your control suite. I am very, very disappointed at the changes. While "RadChartView", whatever that is, may ultimately be faster upon execution, the syntax is not intuitive. Therefore, one of the major benefits to purchasing a RAD control suite is lost.
It would go a long way toward helping your cause if all of your documentation for "RadChartView" would stop referring to that as a concrete class. It isn't. Also, there needs to be a side-by-side comparison of the XAML that it takes to replicate charts with the new control library. To wit, MVVM examples such as triggers are few and far between. The code-behind "solutions" are not that desirable for a large segment of XAML developers.Finally, the real world doesn't type in data points. It binds to data. This needs to be the focus of your documentation and demos. The overly simple examples serve virtually no purpose.
Users be warned: One day Telerik will decide to drop the old charting components and all of us will be forced to update our markup and underlying code. That will be a very costly day if the documentation is not dramatically improved. I am essentially stuck in that hell now. It's not a lot of fun.
We are sorry to hear that you are having problems with our controls. We do know that the XAML parser gets confused because there are two different classes named LineSeries in the different Chart and Charting assemblies. However, it was not an option to give a different name to the LineSeries in the new control. One can simply use a namespace and not the schema:
xmlns:chartView
=
"clr-namespace:Telerik.Windows.Controls.ChartView;assembly=Telerik.Windows.Controls.Chart"
xmlns:oldChart
=
"clr-namespace:Telerik.Windows.Controls.Charting;assembly=Telerik.Windows.Controls.Charting"
It is true that the ChartView is not a control, but it is a set of controls. However, these controls serve the single purpose of visualizing data through a chart display and it has proven convenient to reference the whole set as a single component.
We do not suggest using the old control because of many reasons (limitations due to legacy issues, performance, styling...). Plus, there is a newer version which is much more powerful, flexible, easy to set up and is very very fast. We do not suggest you use both of the controls in a single project because it might lead to compile time and run time errors. Not to talk that someone might get very very confused because of the relatively same names. The new control is set up in a different way than the old one and we know that this might seem a bit unintuitive at first, but this is a different control and one should not expect the same creation notion. Developers that never used the old control become acquainted with the new API very easily.
Here are our QSF examples where you will find that all examples are used in a data bound scenarios. If you have not seen our SDK demos you can find them here.
We hope that you will be able to fully remove the old RadChart from your project and have a great experience with using the new ChartView!
Regards,
Petar Marchev
Telerik
Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
Sign up for Free application insights >>