Code Clean-Up Serialization

[RadvileSaveraiteFemtika]

Changed serialization because it did not work as intended. While making a small change to functionality tidied the code a little bit more.

[Dirkster99]

Can you please comment on what did not work as intended and does now work(is improved?
It would be great if you could name test cases that can be verified, thanx

[RadvileSaveraiteFemtika]

I will correct myself, since this code was written over a year ago and I forgot the exact purpose of it. There were a lot of warnings in the output during serialization/deserialization. This fixes them and cleans up the code.

[Audrius-Femtika]

Exception System.IO.FileNotFoundException is handled inside xmlserializer. However, we prefer no exceptions. For example, we wanted to get all exceptions rised in our app to trace root of bug. There for we asked visual studio to stop for debuggin on any risen exception, and we got many exceptions on Docking windows XML serilizer.
There is correct way to avoid this, if you are interested in more details :
https://stackoverflow.com/questions/1127431/xmlserializer-giving-filenotfoundexception-at-constructor

[Dirkster99]

@RadvileSaveraiteFemtika
@Audrius-Femtika

I tend to rather not change the serialization unless something crucial can be won here and looking at the StackOverflow entry makes me think we should rather not merge this since the serialization is otherwise not changed in terms of fixing bugs or other crucial things, right?

[Audrius-Femtika]

We use it and it is working fine. Windows are saved and loaded correctly. It does not change serialization itself. It just changes the initialization of the serializer. This prevents first chance exceptions. This helps to debug programs when Juniors simply does try.. catch... and silently handle "all error". Then I need to debug "all thrown" even handled exceptions. So, I think this is a big win for big projects! ;)
I really prefer to join it, as we could keep in sync your project in our product. But in the end, it is your call ;)