They are used by the page and the XObjects drawn on it and deal with the overlaying of the colors. These groups are described on page 556 of PdfReference 1.7.
we are using the RadDocking.LayoutChangeEnded event to store the docking layout (via RadDocking.SaveLayout) after the user has changed it.
When animations are enabled (default) everything works as expected and all groups, split containers, and panes are included when in the XML written by RadDocking.SaveLayout.
However, when disabling animations (either using AnimationManager.IsGlobalAnimationEnabled or custom styles for RadWindow and/or ToolWindow setting AnimationManager.IsAnimationEnabled to false) the RadDocking.LayoutChangeEnded event is raised too early.
The faulty behavior can be reproduced with the attached demo application as follows:
1. start the application (App.xaml includes a style for ToolWindow with animations disabled)
2. drag the pane "Solution Explorer" out of the application to create a new tool window
3. drag the "Solution Explorer" tool window onto the "Properties" pane's compass and drop it below "Properties", so that "Properties" and "Solution Explorer" are both pinned right in the application above each other
4. when inspecting the layout written to the "Output" pane you will find that the entry for the RadPane "Solution Explorer" is missing
Any additional change to the docking layout (like resizing a pane) will update the layout and show all panes again.
When enabling animations in the ToolWindow style the above steps will result in the complete layout being written to the "Output" pane.
Please let me know should you require further information for reproduction of this bug.
I think that deploying scenario for applications and protecting dll-s are complicated. I think that better way is to use control panel. I want to send you needed informations through control panel, a and I want to provide me my version of dll-s that are protected and I can use it in my app. You build it on your own. The way you are doing it now is complicated, and can produce issues.
It would be nice to have some additional public properties and commands for ExplorerControl. For example:
Thanks for your consideration!