ValidatingTopLevel - Breaks Client Code in DEBUG

[najak3d]

This only breaks when working with Avalonia DEBUG mode.

We are developing Urholonia, which uses Avalonia Source code in Debug Mode. The recent addition of "ValidatingTopLevel" broke us, because we need to be able to access our "UrhoWindowImpl", as follows:

return ((Avalonia.Controls.Window)this.VisualRoot).PlatformImpl as UrhoWindowImpl;

The problem is that in Debug mode, this returns null.

Our UrhoWindowImpl has several members and properties that are essential. We are rendering a 3D Urho Scene to an Avalonia control, inside of Urho, which looks like this:

Here we have Urho, rendering the AvaloniaControlCatalog app to an Urho-UISprite. But then inside of this Control Catalog, we've added an "UrhoView" which needs access to the "UrhoWindowImpl" to make all this work.

So we have Urho hosting an Avalonia Window, which then is hosting ANOTHER Urho Scene!... The aim here, is that Avalonia will become BOTH the Game Editor Toolset, AND the In-Game UI at the same time.

And we are currently broken (Debug mode only) by the latest ValidatingTopLevel class.

[grokys]

I'm not sure the validating later is needed since #7477 got merged, what do you think @kekekeks? Given that we should now be nulling the platform impl, is there anything that would be caught by the validating layer but not nullable annotations?

The one thing that comes to mind is if someone saves a long-standing reference to the platform impl, but I'm not sure if it's worth complicating things for that case? We could at least add an IsDisposed property to ITopLevelImpl for that so it can be manually checked?

[Gillibald]

Adding IsDisposed to ITopLevelImpl would allow us to still validate every method call but we no longer need to expose the wrapper to the outside world. In my opinion, there should be a base class for the TopLevelImpl that aligns expected behavior.

[najak3d]

PERFECT, THANKS!