After loading saved layout docksite visual tree hierarchy is changed causing exception in our code.

Hi Piyush,

With docking windows, the layout could change at any time.  Any docking, auto-hide, float, etc. operation will create new containers and get rid of old ones as well.  You should never directly name or reference any SplitContainer or ToolWindowContainer since those are transient controls and may or may not be there after docking hierarchy changes.

Further, restoring a serialized layout will effectively close all tool windows and then reopen them based on the serialized layout data.  This means that new containers are constructed at that point and the old ones are invalid.

That being said, things like the DockSite and the ToolWindow instances are retained throughout docking and layout changes.  Thus if you wanted to dock one tool window to the bottom of another, you could do:

toolWindow1.Dock(toolWindow2, Direction.Bottom);

Hi,

Thanks for your quick response.
I still have two queries regarding this.

1) As suggested by you that new container can be created any time when layout changed and also when we load serialized layout data. This could break automation.
Is there any workaround so that automation did not get impacted?
Are the ToolWindow name remain same or they also get changed?

2) I have sent you a sample regarding this issue. In that sample when we first click on “LoadLayout” and then on “Snap” in this case it is throwing exception as toolWindowContainer parent is null. Is there any workaround for this?

Thanks,
Piyush

Hi Piyush,

1) The ToolWindow.Name will always remain the same since the ToolWindow instance is retained during layout changes.  If you need to do automation, you would have to look at the tool window's content based on where the tool window is currently located.

2) For the sample, per our previous reply, you shouldn't ever reference containers like SplitContainer or ToolWindowContainer since those will go null after various layout changes.  Instead, you can reference other ToolWindow instances or DockSite.  Those will always be available and you can dock against those.  If you want to default dock something on the bottom of the layout, target the dockSite with your Dock method.  That will work.

Hi,

I want to know how docksite serializer read the xml and creates the window at appropriate position; so that we can also implement same logic in our code.
I can use serializer to save the layout as xml but i can not load this xml because its changing hierarichy and because of this our automation is breaking.

Please help me regarding this.

Thanks,
Piyush

Hi,

I have updated my sample and sent to you.
In this sample as suggested by you I have docked toolWindow with respect to docksite instead of ToolWindowContainer.
In this scenario I have noted two issue that is:
1) Multiple ToolWindowContainer entries:
• If we click on Snap button(use to dock toolwindow at bottom of docksite) multiple times than in saved xml we can see it has created multiple entries for ToolWindowContainer.
• This will keep increasing, if you continue click on Snap button. This could raise issues as we are going to save xml for the lifetime of application.
2) Float is not working correctly:
• If we float any window and save layout. Next time if we load layout just before launching main window, float window will be floating outside the application. If we dock this window it will get docked in application but it’s not behaving like child window of application.
• If we minimize application this window does not get minimized and act as separate app/window.

Please sugges tme solution for these two issues.

It's a very complex process and not really anything that can be explained easily.  I'm not sure it would be feasible to implement an external deserialization properly either as there are likely internal members that get set during the deserialization process.

Again, you can't rely on SplitContainer or ToolWindowContainer instances remaining throughout the lifecycle of an app session since any change (via layout deserialization or simple docking) will alter the hierarchy and potentially destroy/create container instances to accommodate the updates.

What you can do is rely on DockSite always being there and also rely on the ToolWindows being there.  If you walk up the tool window's logical parent tree to the DockSite then you can modify/access containers that way.  But you have to dynamically get those containers as you need to access them since they could then later change based on the layout changes.

For your second message, we haven't received an updated sample so please make sure you rename the .zip file extension so that it doesn't get spam blocked and send it to our support address.  It would be helpful if you include the related questions in the email you send there so that all the information is together.

In our reply to your other thread, we talked about using hosted rafting windows which may work for your last two questions.

I have sent you updaate sample again.

Hello,

When I run the updated sample, I'm not seeing any issues with the XML increasing entries.  Even after docking all over, it has a single entry for the docked state of each tool window and one for the rafted state of each tool window, which is correct.  Note that I am using our latest 2015.1 version, whereas you were referencing a version that is several years old.  There could have been bug fixes in this area since the one you referenced so I would urge you to move to the latest, or at least try it via an evaluation download, if you think there is a bug in the old version.

Hi,

Thanks for your response.

I agree that we are using old version of binaries and we should move to latest one. But as of now we cannot move to new binaries it will take some time.
For now can you please provide me some workaround for this so that I can make it work.

Thanks,
Piyush

I don't think that workarounds are available since they are bug fixes that were made in later versions.  Your company let your subscriptions lapse several years ago, so I would recommend that you purchase new WPF Studio licenses to restart subscriptions and then we can add any older version you need at that point to your account.  Once you have active subscriptions again, you would simply write our support address and ask for the older version you'd like, such as an 2011.2 version, and we'd get that in your account.  That would allow you to keep a version close to what you have without jumping up to 2015.1.  If you would like to start new subscriptions contact our sales address and they can help you determine the pricing for your needs.