To explain:
Within each module in our application, I am using a RadDocking control to provide a menu panel that is permanently docked to the left hand side of the screen. This pane can be pinned/unpinned but cannot be floated or closed by the user. On this pane I'm then displaying a RadPanel menu system; each option displaying a different 'screen' within the documentHost of the docking control.
The problem arises when the 'screen' being displayed within this documentHost also uses a RadDocking control for it's layout. For example on one such 'screen' contains a tab control, and on each tab there is a seperate RadDocking Control. (a documentHost with two panes docked left and bottom respectively).
When this screen is displayed the user can undock one of the panes docked to the 'screen' documentHost and dock it with the main appplication DocumentHost (ie outside of the 'screen'). I need to prevent this from happening.
Is there anyway to restrict panes so they can only be docked within their own RadDocking control?
Thanks in advance,
Jonathan
33 Answers, 1 is accepted
Regards,
Miroslav Nedyalkov
the Telerik team
Instantly find answers to your questions on the newTelerik Support Portal.
Check out the tipsfor optimizing your support resource searches.
We know it is doable, but we designed the Docking control to not support this scenario. If we want to enable it we need to do a lot of work. We decision so because nesting docking controls neither look very good, neither user-friendly.
What I could suggest you instead of nesting Docking controls is to use SplitContainers. You could organize your views in such manner that you will not need nested docking controls any more.
Best wishes,Miroslav Nedyalkov
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
In my opinion you should remove the Docking controls from the inner views, not from the main one. As I said the Docking control is intended to be used as the main container.
If this cannot be done the way I suggest, please describe me the scenario and will try to help you to figure out a solution.
Miroslav Nedyalkov
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
Let's take a typical application where we have some type of TreeView displaying all the folders and files in my computer. Now, I want the user to be able to display the properties of the folders/files each in a new Tab (RadDockPane). However, inside each "tab", I need a Docking "site" that has pin-able regions that the user can ONLY pin or dock inside that area only because they pertain only to that particular view. These dockable regions cannot be docked outside of that area (i.e. they cannot be docked to the main Shell).
The application we're developing needs this capability not only from a developer perspective, but the client has asked for it as well! So, with the way Telerik is currently structuring the Docking controls, I cannot have the "tabbed" documents and also have "docking" containers inside those tabs. We will be moving back to SandDock controls for now because this is an immediate need. Hopefully your team can see the need for this.
I think you already have the structure for it with your controls. My initial thought is to change the logic of your RadPanes so that they cannot dock within another RadDocking site. This would then give us the ability to have another RadDocking site within a RadDocument (or any child container really). It looks like your just using a Tab control under the hood anyway, and there has never been any limitations put on Tab controls that they couldn't have other tab controls within them so I think this limitation that's been placed on Docking controls is bogus and has probably caused coding hurdles that needn't be there.
Thank you.
I understand your need, but we currently cannot implement this feature. We will take into account your requirement and hopefully implement this feature.
Regards,Miroslav Nedyalkov
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
Currently we don't have plans to implement this feature. We are planning to implement a feature, that will allow you to accomplish all scenarios that could be achieved by nesting docking controls, but it is not scheduled yet. Could you please share your scenario with us? This way we will be able to consider your needs when we start working on the feature.
Kind regards,Miroslav Nedyalkov
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>
Now, thinking in the context of PRISM, same context, you have a Shell. However, each Module which loads may have other "Views" in them that also need to maintain their own docking "contexts". It's the same scenario as above, but the views are loaded on demand and the shell has no control over what controls are placed on them.
Thank you very much for your feedback - we will consider it when working on this feature. I have one more question - do you need separate AutoHide areas for the inner Docking controls for hosting the unpinned panes or you prefer the unpinned panes to go to the root docking control?
All the best,Miroslav Nedyalkov
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>
-David
But, if it's just as easy to pass along which "Docking" control so that we can programmatically tell the panes what their auto-hide area should be... all the better. But the main point I think for most of us here, is that the Panes registered with the docking site should stay ONLY within their area and NOT be dockable with the "outer" or "Main" docking site. That should simplify things greatly because you shouldn't need to reprogram any of the logic for saving docking layouts or anything - each docking site would just save and manage it's own panes.
I can't tell based on the description:
"Implemented a property(ConstraintAutoHideArea) allowing the Panes to go outside the Docks boundaries"
If this property is set to true then the AutoHideArea's fly-out is not constrained to the bounds of the Docking control. This could be useful if you are using the Docking control as a sidebar next to the main part of your application, but the docking control itself is much smaller than the widgets in the fly-out.
Hope this makes sense.
All the best,
Miroslav Nedyalkov
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
So I assume there are no firm plans to add any of the features discussed in this thread?
We couldn't include these features in our plan for the Q1 2013 due to more urgent features and issues that need to be fixed, but we will definitely work on them for Q2 2013 release.
All the best,
Miroslav Nedyalkov
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
Are there any plans to work on this in the next release?
We are already working on this scenario and we already completed our research. We will be targeting to finish the development for 2013 Q3 and to include it in this release.
Hope this time frame is OK for you.
Regards,
Miroslav Nedyalkov
Telerik
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
If you are targeting to finish the development for 2013 Q3 than why in the related PIT http://www.telerik.com/support/pits.aspx#/details/Issue=2304 I can see:
Status = open
Scheduled = Not Scheduled
Shouldn't these parameters have different values?
Unfortunately as this feature is a major one that could possibly change many of the already built-in functionalists of the RadDocking control and introduces breaking changes we didn't managed to implement it for our Q3 2013 release of RadControls.
The tasks for our next official release haven't been planned and we will do our best to add this major feature in the planning for that release.
Regards,
Vladi
Telerik
Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
Sign up for Free application insights >>
We are now in 2015 - has this feature been implemented yet ?
The strange thing I can nest DevExpress docking inside Telerik RadDocking with no problems but when trying to nest RadDocking I get an error
Can you please advise
Regards
The nested Docking feature has been already implemented - for more details you can check the following article:
http://docs.telerik.com/devtools/silverlight/controls/raddocking/features/nesteddocking
And example:
http://demos.telerik.com/silverlight/#Docking/NestedDocking
Hope this helps.
Regards,
Kalin
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.