Call Render() automatically when plottable content (not count) changes

ScottPlot Version: 4.1.15

Operating System: Windows 10

Application Type: WinForms

Bug Description: First signal selected renders as expected. Updating a plot with a different signal does not cause the plot to re-render (i.e. first signal continues to be displayed). If I change the number of signals (e.g. I select 2 signals), it does re-render.

Reproducing: See code sample below.

// ListBox control fires this event. Multiple selections allowed. Fires as expected.
private void SignalLb_SelectedIndexChanged(object sender, EventArgs e)
{
    var lb = (ListBox)sender;
    List<string> selectedSignals = new();
    foreach (var item in lb.SelectedItems)
    {
        var signalName = item.ToString();
        selectedSignals.Add(signalName);
    }
    var rtData = SocketClient.GetRealTimeDataResponse(selectedSignals.ToArray(), 60);
    var plot = TrendPlot.Plot;
    plot.Clear();
    plot.XAxis.DateTimeFormat(true);
    plot.Legend(true, ScottPlot.Alignment.UpperLeft);
    foreach (var signal in rtData.Values)
    {
        AddSignalToPlot(signal.Key, signal.Value);
    }
    plot.Render();
}

private void AddSignalToPlot(string name, Dictionary<DateTime, object> data)
{
    var plot = TrendPlot.Plot;
    try
    {
        double[] xs = data.Select(x => x.Key.ToOADate()).ToArray();
        double[] ys = data.Select(x => Convert.ToDouble(x.Value)).ToArray();
        var scatter = plot.AddScatter(xs, ys, label: name);
    }
    catch (Exception ex)
    {
        MessageBox.Show($"Error while plotting signal: {ex.Message}", "Plot Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
    }
}

[bftrock]

Thanks for the attention, @swharden ! Using the Render call after modifying the plot fixes the behavior for me, as you suggested. I’m not sure of the best way to document it. Also, this is a great addition to the CS community, so thanks for your effort!

[bclehmann]

It looks like they’re unique even when called in rapid succession.

You are correct, GUIDs/UUIDs are often used as the primary keys in databases (or ID or similar thing in non-relational DBs) because they are considered to be unique, even across tables or servers. There’s a whole debate over integer vs GUID vs string primary keys and their implications, especially around their performance as clustering keys. It’s a google rabbithole that’s come up surprisingly often for me recently.

They’re considered to be unique because they’re 128 bit numbers, so when properly generated the chances of repetition are beyond miniscule.

As for the CollectionChanged<T>, that’s nice, I hadn’t known there was a built in class. Probably makes more sense to have it on the object rather than requiring us to remember to keep track of it ourselves.