SciChart® the market leader in Fast WPF Charts, WPF 3D Charts, iOS Chart, Android Chart and JavaScript Chart Components

1
0

Hello there,

I just updated SciChart from 6.4.0.13629 to 6.5.1.26063.

We used the mentioned function to export a chart to PNG as a stream, to include it in our PDF generation.

I played around with the parameters, but none seemed to work.

Since the update, we encounter the following exception:

System.InvalidOperationException: 'UIElement.Measure(availableSize) cannot be called with NaN size.'
   at System.Windows.UIElement.Measure(Size availableSize)
   at SciChart.Charting.Visuals.SciChartSurface.PrepareSurfaceForExport(Double width, Double height)
   at SciChart.Charting.Visuals.SciChartSurface.CreateCloneOfSurfaceInMemory(Size newSize)
   at SciChart.Charting.Visuals.SciChartSurfaceBase.qem(Boolean pu, Nullable`1 pv)
   at SciChart.Charting.Visuals.SciChartSurfaceBase.qel(ExportType pr, Boolean ps, Nullable`1 pt)
   at SciChart.Charting.Visuals.SciChartSurfaceBase.ExportToStream(ExportType exportType, Boolean useXamlRenderSurface, Size size)
Version
6.5.1.26063
  • You must to post comments
0
0

Hello Frederik,

As far as I can understand from the error message
1. You’re using Export to Stream with a different size(which uses serialization under hood)
2. it fails on PrepareSurfaceForExport() mehtod that is used for offscreen rendering for the ‘cloned’ SciChartSurface

It seems that problem might be with one of it’s inner elements, so I have a few questions for you:
– Did you experience such problem with the version v6.4.0.13629
– Are you using some custom controls \ elements in SciChartSurface?
– If so can you remove them and tell us if it still fails?

  • You must to post comments
0
0

Hey Nazariy,

thanks for your response!

We did not experienced the same problem with v6.4.x, but another problem. We had a workaround which was hammering the .ExportToStream() method, until it worked.
It was this one: https://www.scichart.com/questions/wpf/exporttofile-exception-the-provided-dependencyobject-is-not-a-context-for-this-freezable

I’ll check for custom controls and come back to you.

  • You must to post comments
0
0

In fact, the SciChartSurface object is not a UI object. We create the object in code. But before returning, we set a theme on it, with the Charting.ThemeManager. I have the feeling this could be the source of the issue. How can I verify this?

As far as I can make out, there are only to LinearGradientBrush elements declared in the ResourceDictionary, besides several Color and Brush and SolidColorBrush elements. Nothing really which would set a size in any way.

EDIT: well the LinearGradientBrush has a StartPoint and EndPoint property set in XAML. Could this be a hint?

  • You must to post comments
0
0

Hello Frederik,

To verify where the real problem is I can suggest you to do following steps:
1. remove everything from SciChartSurface except surface itself and it’s Xaxis Yaxis.
2. Perform export and see if it crashes fails
3. if everything is OK, add next inner element (renderable series) and do export, if it fails than it’s our guy.
4. Also you can prepare some small sample application that reproduces the problem and send it to us so we can investigate it on our side.

For me it seems that there might be some custom element\control that after serialization get’s it’s width\height equals ‘NaN’. So another way to diagnose where problem is – is to add width and height sizes to all UI elements that are used, like PointMarkers(width, size), some Annotations, etc.

  • You must to post comments
0
0

Hey Nazariy,

I did remove all properties from SciChartSurface object and the theme when initializing, so I only initialized the bare object and the exception is still thrown.

I also tried to set the useXamlRenderSurface parameter to false, still no luck.

  • You must to post comments
0
0

Any update on this?

  • You must to post comments
0
0

Hello Frederik,

It’s hard to investigate this problem without seeing the exact code that causes the problem. I’ve modified one of our examples that demonstrates ExportToStream() usage, can you try it and confirm it works on your side too? And if so can you modify this example so it starts reproducing the problem?

please find exmaple here: ===>>> https://1drv.ms/u/s!ApXFjaRTY-1SgRspmZkALNe2iHPO?e=0ftfc6

  • You must to post comments
0
0

Hey Nazariy,

thank you for your answer.

Sorry for not providing a sample, which reproduces the problem.

Luckily I was able to fix the issue with the help of another colleague!

The issue seems to be the SciChartSurface object itself: if you create the SciChartSurface in code only(!) – so not within UI, a Window, whatsoever – no “sizes” like Height, Width, etc. are set, but show NaN. We set all “sizes” we could find and were able to call .ExportToStream() method without the mentioned exception. So there is no custom control on our side.

Unfortunately I cannot download your sample project, due to restrictions of my company.

Hope this helps somehow.

  • You must to post comments
0
0

Hello Frederik,

From what you’re saying, I can understand that you’re doing something like OffScreen export\rendering ? And indeed if Surface is not rendered and it’s sizes are not specified, then it’s Actual size and size will be NaNs, that for sure will lead to this problem.

You can take a look at this example => https://github.com/ABTSoftware/SciChart.Wpf.Examples/tree/SciChart_v6_Release/Sandbox/CustomerExamples/OffScreenExportExample

As for my example I’ve simply modified our LineSeries example, added there a button that on click do something like this

private void Button_Click(object sender, RoutedEventArgs e)
    {
        var path = @"D:\Exported\TestStream.png";            
        var stream = sciChart.ExportToStream(Core.ExportType.Png, false, new Size(2000, 1000));

        using (var fileStream = File.Create(path))
        {
            stream.Seek(0, SeekOrigin.Begin);
            stream.CopyTo(fileStream);
        }

    }

and it was working, but now I see that it’s probably not your case, as you’re doing some offscreen export\rendering.

  • You must to post comments
0
0

Hey Nazariy,

correct, we’re doing offscreen rendering/export. I was trying to communicate it with “in code”, but the term offscreen is definetly more precise.

The GitHub examples are good! Did not thought about looking for some, while trying to fix the issue.

So, in the end the issue is fixed on our side.

Thanks for your support!

  • You must to post comments
Showing 10 results
Your Answer

Please first to submit.