NotifyPropertyChanged in ListItem throws NullPointerException a lot

[amund7]

I think this is the cause of your (BrianMan) problems with the graph not auto-updating, the Oxyplot graph was supposed to do that when the property "Points" changed. But after a lot of refactoring something is causing this to throw the null exceptions. I've tried looking back at the changes but got stuck.

It is actually the PropertyChanged function that is null, and I don't understand the logic of that, tried googling it to but couldn't find anything useful.

Do you guys have any idea what could cause this?

For me this causes a lot of slowdowns, and the graph window is sometimes behaving erratically (not auto-scaling), and of course throwing constant null exceptions makes the whole thing super slow.

[Bokonon79]

Maybe I'm missing something, but I don't see anywhere in the code where the ListElement.PropertyChanged event handler is assigned to. I looked in the history for ListElement.cs and couldn't find a version where PropertyChanged was assigned a callback.

Do we know what the intended callback method(s) are supposed to be? Something in MainWindow.xaml.cs?

[amund7]

This is the WPF data bindings subscribing to these events.

public class ListElement : INotifyPropertyChanged

and that these are 'subscribed' by the wpf system. So that when

` foreach (var i in items)
Graph.Series.Add(
new LineSeries() { StrokeThickness = 1, LineStyle = LineStyle.Solid, Title = i.Value.name, ItemsSource = i.Value.Points });

    Graph.InvalidatePlot(true);

`
(from MainWindow.cs)

key here is the ItemsSource = i.Value.Points

That causes the "Points" property of MainWindow to be subscribed by the OxyPlot window.
However, Oxyplot says it does NOT support NotifyPropertyChanged properly, which is why I still need to call Graph.InvalidatePlot(true) to refresh the graph window.

I just tried an old checkin of mine from July 2018, that does not throw ANY null pointer exceptions in this PropertyChanged handler, and the whole screen updates seem a lot smoother.

Probably this is something simple and stupid, I noticed Brian-Man has broken the ListItem class into a separate file, maybe that file is not public, or some other access or namespace problems so the MainWindow WPF can not reach it properly ?

[Bokonon79]

Got it, I see the connection now.

It looks like the PropertyChanged event handler isn't wired up by OxyPlot until you actually select the graph tab, or select a different ID to graph, so perhaps the exception was being thrown prior to either of those happening.

Interesting that the graph seemed to work more smoothly in an older commit... I wonder what changed? ListItem class is public, and the graph seems to be able to add/remove the PropertyChanged event-handler without issue.

[amund7]

No, in the earlier builds nothing happens with these until you select the graphs tab, and actually select some items to graph. If you turn on all exception and run it in debug, you will see that the older builds does not throw any nulls in that area.

Newer builds seem to throw null every time, and not working at all. The Pull Request I merged from Scott recently didn't really help, it just checks for null, and does not throw any exceptions, but the result is this handler does nothing.

Before that, Brian-Man added a lot of code to fix his issue that the graphs didn't auto-scale. I tried telling him that this was never an issue, but obviously it had happened when he started working on it.

The end result is not really that dramatic, but it seems the graphs will auto-scale when you start it, but not as it continues rendering. Meaning, if you switch packets while the log is running, the graph is correctly scaled, but if your signal goes higher or lower while watching it, it goes outside the window. On older build they would always scale correctly.