Dear SciChart people,
when trying to export a SciChartSurface instance present in a view (i.e. modified by zoom and series visibility settings etc. done by the user in the UI), it seems that its member functions
may only be called from the UI thread – invocations from a background thread yield an InvalidOperation exception
So for the period of exporting, the application stays unresponsive even when “useXamlRenderSurface=false” is set in the call.
This does not change when trying to clone the surface, using a derived SciChartSurface class (still in in the view) that allows for cloning (cf . the SciChartEx class in the “CreateAnnotationsDynamically” SciChart example): calling CreateCloneSurfaceInMemory is still only allowed on the UI thread.
If one accepts this, but tries to continue with a background thread on the cloned surface’ s ExportToFile instance, it still mandates using the UI thread, so no escape …
Any ideas to go away from the UI thread in this scenario?
Thanks a lot.
I noticed that there are problems when I try to add data series, create renderable series, or annotations while the view that hosts the scichartgroup and/or scichartsurface(s) is/are not yet initialized/rendered. Could this be a bug? After all it should not matter when the view is rendered; when it is rendered its elements bind to the matching properties of its viewmodel, no?
This poses problems for me because I am forced to take the viewmodel-first approach. So, when I create an instance of my viewmodel and then invoke methods in the viewmodel that add data series and render such I am experiencing errors (the rendered series is not displayed on the chart, though annotations strangely are).
I identified the problem to be 2-fold, one is that I have to create renderable series on the UI thread (solved that, no issue) but my other big problem is that the view is actually not instantiated/rendered unless the view is in focus/visible which is not the case during runtime when data series are added via viewmodel.
How can I solve this problem?