VinnieP79

Looks like I forgot to post a conclusion to this, but the RC1 DLL does not exhibit this behavior. Good job!

I'm looking into some memory issues with our app, and it looks like the ChartFX for WPF chart is potentially one of the heavier items. I created a new WPF project and added the following code to Window1.cs: using System;using System.Diagnostics;using System.Windows;using System.Windows.Threading;using ChartFX.WPF;namespace TestSolution1{ /// <summary> /// Interaction logic for Window1.xaml /// </summary> public partial class Window1 : Window { private DispatcherTimer _timer; private long _tickCount; public Window1() { InitializeComponent(); _timer = new DispatcherTimer() { Interval = TimeSpan.FromMilliseconds(100)}; _timer.Tick += new EventHandler(_timer_Tick); this.Loaded += new RoutedEventHandler(Window1_Loaded); } void _timer_Tick(object sender, EventArgs e) { _tickCount++; Chart chart = this.Content as Chart; if (chart != null) { this.Content = null; } else { chart = new Chart(); this.Content = chart; } if(_tickCount % 100 == 0) Trace.WriteLine(_tickCount); //if (_tickCount % 1000 == 0) // GC.Collect(); } void Window1_Loaded(object sender, RoutedEventArgs e) { _timer.Start(); } }} If you run this, you'll see a flickering chart and that the memory allocation continues to increase with periodic but minor Garbage Collections. (See attached image) If you comment out the line where the Chart is being added as content, the memory profile stays flat. So I'm guessing that something special is happening when the chart is actually being displayed - whether it be by WPF or within the Chart itself. What can we do to reclaim all that memory? We hit the 2 GB limit before we can generate 80 charts because things aren't going away. Thanks!

I just tested it, and it works for our usage! Thanks! I love easy fixes.

Microsoft had provided some sample code that would draw a complex "living" visual tree into a "dumb" DrawingGroup. We're looking at incorporating this code into our application. I created a simple test that would render a ChartFX WPF chart to DrawingGroup (see attachment). Compile the solution and when the chart appears, right-click anywhere on it and you'll see a DrawingGroup version of the Chart appear in a new window. It looks like a transform or brush is being skipped someplace, and it seems like it's internal to the Chart. There's one border in the tree that isn't freezable in this sample, and I'd assumed this was the cause, but in my own tests using custom-styled charts without the unfreezable border, the problem still appears. I was wondering if you could take a peek and let me know if there's anything I can add to the DrawingContextExtensions.cs class that would handle whatever is happening inside the Chart, or if there's a change you can make internally on your end that would help remedy this. It seems like the former should be possible, as the Chart renders fine but it's just the visual-grabbing that seems to fail. Let me know if there's anything else I can provide that would help. Thanks!

Great news, thanks!

Our product is scheduled for a March 31st, 2009 release. We're wondering what the chances of ChartFX for WPF being out of beta by that point are: Optimistic, Pessimistic, or No Comment?

I ran into this one today and thought it was worth mentioning: I have a chart whose X-Axis labels are string values. "0 - 2", "2 - 4", "4 - 6". Ignore the fact that they have numerics in them, the same issue would probably occur if I had "Strawberry", "Chocolate", and "Vanilla" as my values. Elsewhere in my code, I was doing a clone of the chart, and blindly copying values, such as clone.AxisX.Labels.Format = AxisX.Labels.Format; And I was doing this not even knowing or caring that I hadn't set format on my AxisX labels. The unset default value was AxisFormat.None, which "Displays a Number without formatting." per API reference. Prior to the set, the labels were displaying, after the set, the categorical labels were not displayed, probably because of the API note. This seems like an inconsistency in terms of behavior. If the labels were displaying before I set the format, why should they disappear after I set the format to the exact same value? It looks like this would only apply to categorical string data. Perhaps an AxisFormat.String could be added or the default behavior of AxisFormat.None could be changed?

It looks like my problem is related to the RenderPass event. If RenderPass fires on my wrapped chart (as when I add it as "live" content"), it renders. If RenderPass doesn't fire (like creating an ItemsControl off-screen and using a VisualBrush to paint the container), I don't get series / legends in my wrapped chart. Is this something I can/should invoke in my wrapper? Thanks! ExpressionDark.txt

Ooops. Looks like I left the last line of Window1.xaml.cs uncommented... // Uncomment this to see that the wrapper loads its visual if it's just added inline. stackPanel.Children.Add(product); If you comment that out, you'll see the behavior I described: // Uncomment this to see that the wrapper loads its visual if it's just added inline. // stackPanel.Children.Add(product); Sorry about that.

It works in the simple sample I sent you, but it was not working when I tried integrating it with our main app. I was able to trace the issue back to the point at which we make VisualBrushes of ItemContainerGenerator containers, and I've updated the sample app to mimic this: Sample Summary: The chart and my wrapper sit in a DataTemplate for an ItemsControl's ItemTemplate. The Items of the ItemsControl drive different properties of the chart. In our app it's chart data that changes, but in this sample I just toggle the legend visibility to illustrate why we do this. I grab the individual containers from the ItemsControl and paint them with a VisualBrush because we'd want to pass these around like slides from a powerpoint deck. It pops up the visuals in two separate windows to illustrate why we're using VisualBrushes from the containers rather than leaving the ItemsControl as is. The Issue: The wrapper is displaying the background of the Chart but the series information is lost. If I weren't getting the chart background, I'd believe the issue was entirely on our end. But since the series and legends aren't showing, I'm not sure. I'm thinking I may be dealing on my end with issues that you resolved on your end around April or so, with regards to data templating and such. If so, do you happen to know what the fix was? Any insights you may have would be appreciated. Thanks again for all your help!

Ah, thanks for that! You're right on, as always. I agreethat wrapping is not a fun approach. We initially had inheritance, butwe moved to wrapping to support our users editing the charts. Withoutrestricting what they can change, exposing chart edits would be likeopening pandora's box. In order to change a series color, I had tomake assumptions about the template and what types of brushes wereused, etc. For now, the wrapper saves us these headaches. In ourprevious release, we relied on the editing toolbar that you exposed. Internally,I'm setting up bindings between the outer DPs and the inner ones andI'm also using wrappers for the deep properties.

I'm attempting to wrap a ChartFx chart in my own class, which derives from FrameworkElement: using System.Windows;using System.Windows.Media;namespace ChartWrapperTest{ public class ChartWrapper : FrameworkElement { // The wrapped chart private ChartFX.WPF.Chart _chart = new ChartFX.WPF.Chart(); protected override Visual GetVisualChild(int index) { return _chart; } protected override int VisualChildrenCount { get { return 1; } } protected override Size MeasureOverride(Size availableSize) { _chart.Measure(availableSize); return _chart.DesiredSize; } protected override Size ArrangeOverride(Size finalSize) { _chart.Arrange(new Rect(finalSize)); _chart.UpdateLayout(); return new Size(_chart.ActualWidth, _chart.ActualHeight); } }} And I'm seeing the chart area size correctly, but it's not displaying the default series. The following Xaml snippet illustrates this: <Window x:Class="ChartWrapperTest.Window1" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:cfx="clr-namespace:ChartFX.WPF;assembly=ChartFX.WPF" xmlns:local="clr-namespace:ChartWrapperTest" Title="Window1" Height="Auto" Width="300"> <StackPanel> <local:ChartWrapper /> <cfx:Chart /> </StackPanel></Window> Can anyone spot anything glaringly wrong with this? I've attached a zipped version of the VS2K8 solution with the above code. If I can get this much working, I'll be able to expand my wrapper to expose only the properties I want. Thanks!

Exporting to Xaml or an Xml viewstate is something that would be extremely handy for what I'm doing right now. I basically want a clone of my chart instance and to be able to persist its visual aspects. I tried the traditional xaml-clone method of: Chart clone = (Chart) XamlReader.Parse(XamlWriter.Save(originalChart)); But that yielded me with the default chart. Right now I'm experimenting with what needs to be copied in code versus what can be done via the xaml-serialization clone: public object Clone() { Chart clone = new Chart { AllowDrop = this.AllowDrop, AllSeries = new ChartFX.WPF.AllSeriesAttributes { PointLabels = this.AllSeries.PointLabels }, AxisX = new ChartFX.WPF.Axis { Labels = this.AxisX.Labels, Grids = (ChartFX.WPF.Grids)XamlReader.Parse(XamlWriter.Save(this.AxisX.Grids)), Line = this.AxisX.Line, PositionValue = this.AxisX.PositionValue }, etc. The underlying business need we're trying to address is being able to expose the ability for the user to change and persist visual aspects of the chart at run time. Colors, Point Label Visibility, Chart Style, etc. Please let me know if there's a better way to do this with the current beta. I'm in the trial and experimentation phase at this point. Thanks! Vinnie

I apologize if this has already been addressed, but will the Chart Toolbar that was available in the WinForms version be available in the initial release of the WPF version?

Is it possible to make the legend flow horizontally rather than stacking vertically?