An alternative solution would be return a default legend object in Сrosshair Plottable with a null or empty label field. Then there would be no need to change the existing filter.

@StendProg, Thank you for your reply.

An alternative solution would be return a default legend object in Сrosshair Plottable with a null or empty label field.

So you mean, for example, the following?

public LegendItem[] GetLegendItems() => Array.Empty<LegendItem>();

I thought about that too, but I did the same with the Legend.UpdateLegendItems method as it does something similar.

Shall I change to the solution you suggested?

I mean something like this:

public class Crosshair
{
...
 public LegendItem[] GetLegendItems() => new LegendItem[]{ new LegendItem(this){label = null}};
...
}

We only have 1 Plottable which is out of concept and returns null instead of a LegendItems. Instead of adapting the concept of processing (filters that may be or will appear elsewhere) to a single exception (Crosshair), it may be better to adapt this exception to an existing concept.
I don't know which is better for sure, so the decision is yours, I just pointed out an alternative.

Sorry for the delay.
That's what you meant. Thank you for telling me correctly.

public interface IPlottable
{
  ...
  /// <summary>
  /// Returns items to show in the legend. Most plottables return a single item. in this array will appear in the legend.
  /// Plottables which never appear in the legend can return null.
  /// </summary>
  LegendItem[] GetLegendItems();
  ...
}

As stated in the documentation comments for the IPlottable.GetLegendItems() method, I believe that cross hairs are never put out in the legend.

Therefore, I would like to return null for the said method (Crosshair.GetLegendItems()) as it is now, and use it through a filter.

Thank you @MareMare and @StendProg!

We only have 1 Plottable which is out of concept and returns null instead of a LegendItems. Instead of adapting the concept of processing (filters that may be or will appear elsewhere) to a single exception (Crosshair), it may be better to adapt this exception to an existing concept.

I will implement this now to bring Crosshair into consistency with the rest of the plottables provided with this library

Then there would be no need to change the existing filter

I am happy the filter was updated to protect against null because, even though none of ScottPlot's plottables return null, the user may create their own IPlottable which does, and this fix protects against that case.

In ScottPlot 5 I'll use the nullable project feature to make it clear when functions are not supposed to return null, and it makes sense to me that GetLegendItems() should always return an array (even an empty one) to prevent this issue in the future.

Quick update, wow, lots of plottables were returning null! 4bcf592

Returning null was even recommended in the XML documentation of IPlottable 😅 I fixed that