Pre loader

Different coloured points in a series

Welcome to the SciChart Forums!

  • Please read our Question Asking Guidelines for how to format a good question
  • Some reputation is required to post answers. Get up-voted to avoid the spam filter!
  • We welcome community answers and upvotes. Every Q&A improves SciChart for everyone

WPF Forums | JavaScript Forums | Android Forums | iOS Forums

Answered
0
0

Hi

A couple of months ago I asked if it was possible to plot an XyScatterRenderableSeries (and sometimes a FastLineRenderableSeries) that contained different coloured points – each data point can be in one of many “states”, and the colours are used to indicate these.

I was told it wasn’t possible, so my workaround was to have a separate series for each state, and add each point to the appropriate series based on its state. It’s a bit of a maintenance headache though, as there are often many different states to represent, each requiring its own series.

At the time I was told v2.0 might include support for IPaletteProvider for these series types. The release notes mention FastLineRenderableSeries but not XyScatterRenderableSeries. Did it not make it in?

Regarding FastLIneRenderableSeries, I’m assuming IPaletteProvider only controls the colour of the line and not the point (so it wouldn’t be of use in my scenario)?

Thanks in advance
Andy

  • You must to post comments
Best Answer
0
0

Update: PaletteProvider API in SciChart v3.2+

As of SciChart v3.2 and above, the PaletteProvider API supports scatter charts

enter image description here

The PaletteProvider API allows you to draw a different colour for each data-point of a series. Supported series in v3.2 include Line, Column, Mountain, Scatter, Candlestick, Ohlc. In v3.1 fewer series are supported.

You can see an overview of the API at Change Series Colour Dynamically (PaletteProvider) and a live demo in the WPF Examples Suite -> Using PaletteProvider Example.

Best regards,
Andrew

  • You must to post comments
0
0

We are talking to another customer who is storing a STATE_ID in the ‘Z’ value of XyzDataSeries. This is one possible way to do a lookup to a viewmodel.

Or another is to have a separate List of your metadata objects and use the X,Y value outputted by PaletteProvider to lookup the index in the DataSeries, by using DataSeries.FindIndex (which performs a fast binary search)

  • andyste1
    Thanks for the response. The XyzDataSeries suggestion may be useful, as I could (in my case) store the entity ID in Z, and use it to look up the entity via the view-model (where the chart data is held). Again, I'm struggling to think of how to pass around an instance of the view-model to classes like palette providers and rollovers. What do you suggest for such a thing? Many of my views/view-models are transient rather than singleton, so the palette provider can't just use a service locator, as it wouldn't get the same instance. Regarding the metadata/state idea, my typical use case is as follows. I'm developing a scientific data processing application where I've implemented half a dozen different chart types, with more to come. In most cases the points represent chemical samples, and we need to use colours to represent different sample states such as "ok", "excluded", "quality check fail". Most charts also implement context menus, using hit-testing to see if the user has right-clicked a point. It then needs to figure out which chemical sample the point relates to, and set the menu item text (e.g. "Exclude sample 'foo'") and the command parameter (often the sample object). This is done by implementing some kind of "FindSample" method on the view-model. The mouse-click event handler does the hit-test, then passes the X,Y values to the method, which returns the corresponding sample object. For the metadata/state idea, I was thinking of something like the "Tag" property you find in some of the WPF and Winforms controls - basically just a general purpose object type property in which you can store anything you want. It might be as simple as the DataSeries having an overloaded 'Append(x, y, state)' method. Similarly, there would be a new property 'StateValues'. For it to be useful, the state value would also need to be surfaced to components like rollovers, hit-testing, palette providers, etc. Hope that helps! Andy
  • You must to post comments
0
0

Hi Andy,

Makes perfect sense. In fact its an idea we’ve already discussed internally, to allow DataSeries<TX,TY> to accept a Metadata object (optional) per point, or similar solutions to allow this.

There is only one problem with this though – what should the metadata be in the case where points are resampled? It is entirely possible inside SciChart that 1000 input points becomes 1 output point when aggregated. If there is more than one Metadata point inside here it can get messy.

I guess the current implementation of looking up an X-value would return the first X-Y point with that X-value, and people might have to accept the shortcoming of when zoomed out metadata on hit-test might be a nearest-result and to get full accuracy you will have to zoom in.

What do you think about this?

Best regards,
Andrew

  • You must to post comments
0
0

Hi Andy,

Makes perfect sense. In fact its an idea we’ve already discussed internally, to allow DataSeries<TX,TY> to accept a Metadata object (optional) per point, or similar solutions to allow this.

There is only one problem with this though – what should the metadata be in the case where points are resampled? It is entirely possible inside SciChart that 1000 input points becomes 1 output point when aggregated. If there is more than one Metadata point inside here it can get messy.

I guess the current implementation of looking up an X-value would return the first X-Y point with that X-value, and people might have to accept the shortcoming of when zoomed out metadata on hit-test might be a nearest-result and to get full accuracy you will have to zoom in.

What do you think about this?

Best regards,
Andrew

  • You must to post comments
0
0

Hi Andy,

Unfortunately, ability to draw each PointMarker in different color haven’t been implemented yet, also, as you noticed, though IPaletteProvider works for FastLineRenderableSeries, it doesn’t change point markers on line. But we are working on it and there are some improvements in comparison with 1.7.x, as you can see in our Use point markers example.

Regarding your case, we have an example which demonstrates how to make PaletteProvider working with ScatterSeries. I think you could modify it a bit and use suggested approach too. Please, take a look at attached example and let us know if this is suitable solution for you.

Best regards,
Yuriy

  • andyste1
    Your example looks promising, but a problem is that the palette provider and custom renderable series can only "see" the DataSeries and X/Y values of the point. In my scenario, the logic to decide which point marker to use is more complex than simply examining the point's X/Y values, and would probably rely on data residing in the view-model. So can you suggest a way for either of these classes to gain access to the view-model? I've had similar issues when doing hit-testing, which only tells me the DataSeries and X/Y values of the point that was hit. Here, it's a little easier to handle than above, as hit-testing is usually done in code-behind mouse events, so I'm able to access the view-model. I find myself having to use VM properties or methods to figure out which underlying entity (a chemical sample, for example) the point relates to. This leads on to a feature request: it would be useful if there was a way to store "metadata" against each point in a DataSeries. This could be as simple as an "object" property type that co-exists alongside the X and Y values. It would be a big help in situations like the above, as the information would be readily accessible to palette providers, custom renderable series, rollover modifiers, etc.
  • You must to post comments
Showing 5 results
Your Answer

Please first to submit.

Try SciChart Today

Start a trial and discover why we are the choice
of demanding developers worldwide

Start TrialCase Studies