Wouterdek/NodeNetwork

Grid.SetRow Null Exception with Multiple Controls on Nodes

Sage-of-Mirrors opened this issue · 5 comments

Hello again,

I have encountered an issue that I cannot seem to debug myself. I created a control to handle arrays of floats on nodes, allowing the user to add and remove them as they like. The XAML for the control can be found here.

However, when I encounter situations that have many instances of this control with many elements within them, I get this exception:

System.ArgumentNullException
  HResult=0x80004003
  Message=Value cannot be null.
Parameter name: element
  Source=PresentationFramework
  StackTrace:
   at System.Windows.Controls.Grid.SetRow(UIElement element, Int32 value)

  This exception was originally thrown at this call stack:
	System.Windows.Controls.Grid.SetRow(System.Windows.UIElement, int)

If I force every instance of the array control to have 0 elements, the exception does not occur. Since the error is in how ReactiveUI generates UI elements, I was hoping that you might have some insight into why this occurs and how I can fix it.

Hi,

the information you are providing are not enough for me to pin point the problem, but I am guessing, that recreating the ObservableList on adding and removing items is causing the problem.

You can look at the VisibleInputs ObservableList in NodeViewModel to see how Wouter did it.

But closer to your example: I had a similar problem where the observable list was not working for me. You can try to use T[] instead of ObservableList<T>, since you are not using the functionality of ObservableList anyway.

It seems like this wasn't the issue. Could it be that I just have too many nested controls for the ReactiveUI to handle?

Does this bug still occur with the latest version? If so, a stripped down project that demonstrates this bug would be very helpful for debugging.

I will update to the latest version when I get the chance, and if I still get the issue I will make a project to test it.

Looks like updating fixed it! This may also have fixed #84, since it seems like they were having a similar issue. Thanks!