How to preseve windows during layout deserialization?

Hello,

That is correct per design since it will force a cleared layout before loading anything new from the deserialized layout info.  If we didn't do that, we wouldn't be able to ensure that the deserialized docking windows end up exactly where they should.

Your only option would be to store which documents were open before the layout load, temporarily turn off the destroy documents on close option, load the layout, restore the destroy documents on close option, and reopen all documents that were previously open but are not open any more.

Can you give some more info on this scenario in your app?  Such as do you have any documents in the layout you're loading?  If so, I assume you are trying to keep existing ones open and want to merge the documents from the layout data in with those?

So if window is closed (but not desroyed) during deserialization, the doking site will keep the memory of where it was, and I will be able to reopen it at previous location, correct? If so then it is good, I think I will be able to work around this limitation.

As for scenario... In my app user can select and open a binary data file to view its contents. Some document/tool windows I have are data-specific in a sense, that they are only available when user opens file that has specific content. When user closes the file I save the layout, when user opens the same file again later on - I deserialize it. But I also have windows that are always availible to user, even when no file is open (app settings, task queue, etc.). If any of those windows were open before user opens a file I don't want deserialization to destroy/close them. I believe all of those windows are tool windows, but in my case the distinction between "tools" and "documents" is blurry.

No not exactly.  When a docking window is closed, we leave a breadcrumb behind in the UI that says where it was.  If you reopen the docking window, it locates a breadcrumb for itself (if one is found) and reopens in that exact spot.  Otherwise, it runs through the default location logic, where you can customize via properties and an event where a docking window opens when no breadcrumb is found.

When you load a layout, all the UI structure is cleared, which includes wiping out breadcrumbs.  So after that, any previously open documents that aren't part of the layout deserialization will have lost their breadcrumbs and will fall back to running the default location logic.

For your scenario, I'm not sure if this is feasible but what if you used nested dock sites.  So you'd have an outer dock site that had your always-available tool windows.  Then each "document" in that outer dock site would represent your data file.  The docking window for that data file document would have another dock site inside of it that would have all the tool windows related to that particular data file.  Then you could save/load layouts for those without affecting each other.  The only downside is that you couldn't dock the data file's tool windows in with the outer dock site's tool windows.  But maybe that's not important for you.