Docksite Serialization for ToolWindows with State=Document

Docking/MDI for WPF Forum

Posted 4 months ago by Justin Klein
Version: 19.1.0681
Platform: .NET 4.5
Environment: Windows 10 (64-bit)
Avatar

I've got docksite serialization working, with one exception: any ToolWindow that's docked to the "documents" area (aka that has state=document) is not restored by layoutSerializer.LoadFromString.  Example:

1) Start the app, giving a new/default layout

2) Drag one of the ToolWindows to the "main" document area (and perform any other manipulations of other ToolWindows - resizing, pinning, unpinning, etc)

3) Quit.  Looking at the serialized layout file on disk, it reveals that that window shows isOpen="false" even though it was open:

<ToolWindow UniqueId="63909904-2834-4c05-a216-3edb81b4a079" SerializationId="Options" ContainerDockedSize="232.4,497.2" IsOpen="false" LastActiveDateTime="2019-06-30T18:05:03.3790026-07:00" State="Document" />

4) Re-launch the app.  All ToolWindows are restored, except for the one that was in the main document area.

Furthermore, if I manually change IsOpen="true" in the xml, re-launch, & re-quit...it has again changed it back to false (even though I did nothing in the UI, and it didn't show up when I launched).

Why does it keep resetting any ToolWindows with State=Document to IsOpen=false?

Comments (10)

Posted 4 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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!


Actipro Software Support

Posted 4 months ago by Justin Klein
Avatar

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!

Posted 4 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.

[Modified 4 months ago]


Actipro Software Support

Posted 4 months ago by Justin Klein
Avatar

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

By default, only layout information of tool windows is serialized. The full layout, including document windows and the MDI layout, can be saved by setting the DockSiteLayoutSerializer.SerializationBehavior to DockSiteSerializationBehavior.All

These are still Tool Windows, not Document Windows.  I had read the documentation and deliberately not set that value because of the above text.  It seems like this is actually what would be accurate:

By default, only layout information of tool windows that aren't docked to the MDI area is serialized. The full layout, including document windows and tool windows docked to the MDI area, can be saved by setting the DockSiteLayoutSerializer.SerializationBehavior to DockSiteSerializationBehavior.All

Answer - Posted 4 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 4 months ago by Justin Klein
Avatar

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 :/

Posted 4 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.

[Modified 4 months ago]


Actipro Software Support

Posted 4 months ago by Justin Klein
Avatar

>>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 :)

Posted 4 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 4 months ago by Justin Klein
Avatar

Great, thanks! :)

The latest build of this product (v2019.1 build 0683) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.