Hi,
On a bare bones page with just a simple XamChart, I'm running into the following problem:
If I create the chart in markup, the mousedown-hittest sequence returns HitTestArgs with the clicked DataPoint.
However, when I create a series of DataPoints in code, the SelectedObject in the HitTestArgs is always null.
This XAML produces correct result for MouseDown/HitTest:
<igCA:Series ChartType="Bar" Label="Series 1"> <igCA:Series.DataPoints> <igCA:DataPoint Label="Point 1" Value="2" /> <igCA:DataPoint Label="Point 2" Value="1" /> <igCA:DataPoint Label="Point 3" Value="3" /> </igCA:Series.DataPoints> </igCA:Series> </igCA:XamChart.Series>
But when I comment out the DataPoints section and replace it with this code:
Series sr = chart.Series[0];
for (int i = 0; i < 4; i++) { DataPoint dp = new DataPoint(); dp.Value = i * 3; sr.DataPoints.Add(dp); }
The Graph looks identical, but HitTestArgs SelectedObject is always null.
Ideas?
I'm trying reproducing this issue with XamChart v8.2:
<igCA:XamChart x:Name="chart" MouseLeftButtonDown="chart_MouseLeftButtonDown">
...
{
InitializeComponent();
dp.Value = i * 3;
sr.DataPoints.Add(dp);
}
And the HitTestArgs SelectedObject seems ok. Can you apply the last hotfixes and see if this issue still exists?
Your code yields a null SelecteObject on my machine, with version 8.2 of the library (and .net 3.5 sp1). Since I'm using an evaluation version, I can't d/l the hotfix.
Thanks for the info.
I guess everything will be ok in next release of WPF, which is scheduled for April.
Hi again,
In the meantime, my client, who has a registered copy of IG/WPF, let me run the test project on his machine. I got the same result, until I removed the call to chart.Refresh() - which got there as part of my attempts to make hitTest work. Without the call the Refresh, hitTest works as expected.
Edit: btw, whenever hitTest does find a datapoint, the mousebutton event handler is called twice.
You can add:
e.Handled =
in this case the event handler won't be called twice.
We fixed some issues with chart.Refresh() recently and I'm not able to reproduce this with our latest build, so in next version this should be ok.