Docksite Serialization for ToolWindows with State=Document

Hi Justin,

It's hard to say without debugging a sample that shows it.  We haven't had reports of this happening and I don't see it happening in our Layout Serialization QuickStart.  Can you make a new simple sample that shows the issue and send that to our support address, mentioning this thread?  Please remove the bin/obj folders from the ZIP you send and rename the .zip file extension so it doesn't get spam blocked.  Thanks!

Sent.

Note: I just realized that if it fails to build, you might need to just empty the postbuild event (it just does a little dll cleanup/reorganization, but it isn't necessary, so if you have issues, just delete that & it should work).

Thanks!

Hi Justin,

Thanks for the sample.  I believe it's just that you were missing this line in your serializer creation:

layoutSerializer.SerializationBehavior = DockSiteSerializationBehavior.All;

By default, the serializer will only deserialize the non-MDI area.  If you set that property to All, then it will include the MDI area as well. 

Let us know if that resolves it for you.  When I tested with All in our latest 2019.1 version, it seemed to restore the Options tool window to the MDI area ok.

...That fixed it...which means the documentation is wrong.  Documentation says:

Hi Justin,

We looked into this further because it didn't feel right and found the documentation is correct.  It should be restoring this tool window to the MDI area, at least to the active tabbed MDI container, even when only deserializing tool windows.  

We found the bug that was causing the problem in this scenario.  When this particular scenario occurs (deserialing a tool window to MDI with tool windows-only mode), it wasn't locating the tool window properly.  It was only using ToolWindow.Name-based lookups in that scenario and wasn't using the SerializationId to do a lookup for the ToolWindow first.  We fixed it by adding the SerializationId-based lookup before the Name-based lookup.  This is how it should have been.

The change will be in the next maintenance release.  Please write our support address if you'd like to test a preview build.

Is there any disadvantage to just using

layoutSerializer.SerializationBehavior = DockSiteSerializationBehavior.All;

?  It does seem to work fine, & only deserializes toolwindows, as desired.  Unfortunately my license is beyond its year of included updates, & as the above *appears* to be working, I don't think my employer would be willing to spring another $650 for that one change :/

Hi Justin,

The All behavior will simply fully restore any document windows and the MDI area structure.  If you aren't using any document windows, then yes, that should be absolutely fine.

I should also mention that you could use Name instead of SerializationId to work around the bug in the old version too.

>>The All behavior will simply fully restore any document windows and the MDI area structure. If you aren't using any document windows, then yes, that should be absolutely fine.

I am using DocumentWindows - they may be open when the layout is serialized - but they wouldn't exist when the application is first launched, so based on my understanding, they wouldn't be restored (it'll only try to restore DocumentWindows it already finds in the collection when deserializing the layout).  So my understanding is that it effectively serializes some extra data...but when restoring, since those documents haven't been opened, that seriailzed data won't have any effect.

>>I should also mention that you could use Name instead of SerializationId to work around the bug in the old version too.

Thanks for the idea.  If the above works tho, I'll probably stick with SerializationId so I don't have to worry about ensuring that the strings are valid identifiers :)

Hi Justin,

Correct, you are probably ok with the All scenario then since the document window data should get effectively dropped with default serialization options (i.e. no auto-create or lazy load).

Yes, I agree... SerializationId is so much nicer than being constrained by identifier requirements.

Great, thanks! :)