Add a way to recreate a Window without invalidating the existing Object

[DemoXinMC]

Options to recreate a window while reusing the existing Object should be added. While the object on the native side will be changed, the new pointer should be plugged back into the same Window to avoid additional GC overhead or access violations when attempting to work with a Window after recreating it

[eXpl0it3r]

Alternatively: Provide a create function similar to what SFML has on their window.

[charleyah]

Would graphic resources created prior to a window getting recreated still be valid? OGL context thinking sounds.

[DemoXinMC]

Would graphic resources created prior to a window getting recreated still be valid? OGL context thinking sounds.

After some investigation, yes, a graphics resource absolutely persists. This feature would ultimately be a minor tweak to allow the recreation of a window without invalidating the .NET object's pointer

[eXpl0it3r]

I see three-ish issues here:

1. Additional C# allocation for creating a new instance
2. Event handlers need to be re-registered
3. Window reference might become invalid

While 1. is certainly true, given that you'd recreate the window only very rarely, I feel this is negligible.
Number two is something a user could easily forget and rather annoying that one would have to remember this, as such this is one of the strongest arguments to do something about it.
Finally, 3. seems much more like a general lifetime issue and only partially connected to the issue here. If you implement the code "correctly", this shouldn't become an issue.

SFML.Net's API design was deliberately chosen to not use any create() functions, but have only one way to "create" an object and that is via constructor.

Weighing the problems against the design choice, I've come to the conclusion that, I don't want to change this for SFML.Net 2. It's not on a hot path, as such an allocation isn't critical and the inconvenience caused, can be circumvented with a simple function that can be called, so it's not the end of the world.

For SFML 3 or 3.1 3.2 we plan to have functions that would allow you to change the state of a window (and potentially the style as well). At the point we could have those functions implemented in SFML.Net as well.