We just upgraded to 1.2.4 and now we're getting a huge breaking change. Whenever we call "FindResource" from a custom control, it no longer returns the resource defined at the root level that contains the custom control. We then tried to work around this by using VisualTreeHelper.GetParent to climb up the tree to find the root control from the custom control, but that doesn't work either. GetParent() will return null once it reaches the topmost element within the custom control.
This is causing a lot of problems with our theming, and our MultiStyle attached property (since we can't do BasedOn from different .xaml files). Is this the intended behaviour of the FindResource now? If so, how would I either get the root view's resources ?
No, this is not the intended behavior. It was a bug and we fixed it, thanks for your feedback. So for next release you will be able to call FindResource in the Initialized (OnPostInit) event, and Logical tree should also be ready (Parent property should return the logical parent).
The problem now, however, is that I'm getting an exception when I stop the game.
Here's the exception:
Unhandled exception at 0x1EEDFA73: Access Violation reading location 0x00000008
[ 0] [0x1EEDFA73] Noesis.dll!SWIG_CSharpSetPendingExceptionArgument + 0x483 bytes
[ 1] [0x1EEDF91B] Noesis.dll!SWIG_CSharpSetPendingExceptionArgument + 0x32b bytes
[ 2] [0x1EF32993] Noesis.dll!Box_Bool + 0x83 bytes
[ 3] [0x0BE93DD0] mono.dll!mono_profiler_install_class + 0x1af bytes
[ 4] [0x1EE2F46E] Noesis.dll!MouseState_leftButton_get + 0x8884e bytes
[ 5] [0x0BE57B94] mono.dll!mono_domain_get + 0xc bytes
[ 6] [0x1EEE7610] Noesis.dll!SWIG_CSharpSetPendingExceptionArgument + 0x8020 bytes
Found out more information. Managed to fix the cause of the crash, which was caused by one of our controls binding to an ObservableCollection<bool>(). Is this not allowed? Wrapping the boolean in a class and using that in the observable collection seems to be fine and the exception no longer occurs.
Thanks to your collaboration we found the source of this problem. It turns out that one of your custom ItemsControl, with the Style set as a DynamicResource, was alive after NoesisGUI was shut down (because of a circular reference).
In that scenario we were trying to access some internal structs that were already destroyed during shut down. We fixed this issue for the next release too
Lastly, we found a bug with Noesis.dll not being unloaded properly. It was weird that some of our views were getting unloaded fine, but for some reason, this does not. We've narrowed it down to our custom ScrollViewer that we built. We override the styling for the existing scroll viewer for our own, and whenever we show this custom scroll viewer, if we stop the unity game using the play button, it would not let go of Noesis.dll.
This problem was related with the previous scenario too: a control that lives after NoesisGUI shut down. We fixed the problem that prevents Noesis.dll be unloaded or made Unity Editor crash, when a NoesisGUI error occurred during shut down.