Nexted RadDocking Controls

34 posts, 1 answers
  1. Jonathan
    Jonathan avatar
    13 posts
    Member since:
    May 2009

    Posted 20 Aug 2009 Link to this post

    On the project I'm currently working on, I need to be able to nest one RadDocking control within another. The problem is there does not seem to be a way of restricting child docking panes to only dock within their own host RadDocking control.

    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
  2. Answer
    Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 21 Aug 2009 Link to this post

    Hello Jonathan,

    Unfortunately nesting Docking controls is not supported.

    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.
  3. DevCraft banner
  4. Tim
    Tim avatar
    85 posts
    Member since:
    Aug 2008

    Posted 23 Apr 2010 Link to this post

    Can you please integrate this feature?  We also need this due to the way that multiple Prism Modules are being plugged into our "shell".  The Shell itself has its own Docking, but sometimes so do the modules.  This is fully supported in SandDock controls so I know it can be done.
  5. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 23 Apr 2010 Link to this post

    Hello Tim,

     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.
  6. Tim
    Tim avatar
    85 posts
    Member since:
    Aug 2008

    Posted 07 May 2010 Link to this post

    So, after evaluating our application, I can get away with removing docking from the Main Shell, however, I really need the ability to "unpin" the Outlook bar on the left side of the app, is there another way to do that without using docking panes?
  7. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 11 May 2010 Link to this post

    Hi Tim,

     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.

    Kind 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.
  8. Tim
    Tim avatar
    85 posts
    Member since:
    Aug 2008

    Posted 11 May 2010 Link to this post

    Right, so after lengthy discussions with the rest of the developers and managers, it seems we really do need this ability.  I have been doing "dockable" apps for over 10 years starting with Infragistics, DevExpress, SandDock and so on and I have ALWAYS needed the ability to have a Docking "site" within another dockable region.  Now, I know you've probably modeled the docking controls after Visual Studio or Outlook style apps.  These apps are good "starter" apps in that they only deal with one thing: emails and communication or programming.  However, when you're designing a "modular" business application, where each module or "view" has its own self-contained functionality and must have the ability to have dockable areas that ONLY pertain to it, this model of only one Docking "site" falls apart.

    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.
  9. Tim
    Tim avatar
    85 posts
    Member since:
    Aug 2008

    Posted 11 May 2010 Link to this post

    Let me make it slightly more clear.  I don't think there should be nested RadDocking's allowed inside a RadPane, only RadDocumentPanes.
  10. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 13 May 2010 Link to this post

    Hi Tim,

     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.
  11. David
    David avatar
    38 posts
    Member since:
    Oct 2007

    Posted 14 Feb 2011 Link to this post

    I too really need this ability.  Any status on whether or not it has been implemented or has plans to be?  This is currently stopping my development.  I tried nesting RadDocking controls, but like the author of the thread pointed out, it doesn't work.  I would really like to have this feature.  We are also using a Prism architecture.
  12. Tim
    Tim avatar
    85 posts
    Member since:
    Aug 2008

    Posted 15 Feb 2011 Link to this post

    Sorry, you're probably still out of luck.  We ponied up for the DivElements docking controls which work great with multiple Prism assemblies so each assembly can have docking within docking....it's nice!
  13. David
    David avatar
    38 posts
    Member since:
    Oct 2007

    Posted 15 Feb 2011 Link to this post

    Hmmm well maybe having someone recommend on a public telerik forum that one shouldn't go with Telerik but instead another product because their toolkit is lacking is enough to motivate them to get on the ball.
  14. Andrew
    Andrew avatar
    29 posts
    Member since:
    Oct 2010

    Posted 11 Jun 2011 Link to this post

    I definitely need this feature as well.
  15. Andrew
    Andrew avatar
    29 posts
    Member since:
    Oct 2010

    Posted 10 Jan 2012 Link to this post

    Just wondering if there are any plans to implement this (quite popular) feature? As much as I like Telerik, looks like we will have to switch to another docking library because of that :(
  16. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 13 Jan 2012 Link to this post

    Hello,

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

  17. Tim
    Tim avatar
    85 posts
    Member since:
    Aug 2008

    Posted 16 Jan 2012 Link to this post

    I can think of a very simple scenario right off the bat.  You want to have your main "Shell" in the application provide docking controls for a left navigation area, a main content area, and a right-docking area (maybe some kind of ticker?).  However, "Views" that load into the main content area may want to have separate docking windows within them (maybe one has a TreeView inside it that a user can pin/unpin).  The Docking areas INSIDE each content view should NEVER be able to be docked with the main Shell docking controls, because they are not part of that hierarchy.

    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.
  18. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 17 Jan 2012 Link to this post

    Hello Tim,

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

  19. David
    David avatar
    38 posts
    Member since:
    Oct 2007

    Posted 18 Jan 2012 Link to this post

    I also requested this feature a long time ago which is why I'm still getting these alerts, but to answer the latest question, I would say the inner panes should have the option of auto-hiding to the inner docking control or the outer one.  But, if you had to choose, I would say it makes more sense to have it hide to the inner docking control because that is where the pane resides.

    -David
  20. Tim
    Tim avatar
    85 posts
    Member since:
    Aug 2008

    Posted 24 Jan 2012 Link to this post

    I mostly see developers requesting this functionality specifically because they need another inner auto-hide area in separate modules.  If I wanted to have a module's content plug in to another auto-hide content into the "Shell" or "Main" docking area, I would add functionality into the Shell to accommodate registering those types of things (think PRISM Regions or something, or even a simple "IShell.RegisterDockingArea(...)" call).

    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.
  21. Jan
    Jan avatar
    4 posts
    Member since:
    Nov 2011

    Posted 11 May 2012 Link to this post

    Is there any progress on the subject? Is this "feature, that will allow you to accomplish all scenarios that could be achieved by nesting docking controls" scheduled? Our project also requires this functionality.
  22. Tim
    Tim avatar
    85 posts
    Member since:
    Aug 2008

    Posted 11 May 2012 Link to this post

    Unfortunately no.  If you want this functionality you have to use SandDock controls from DivElements.  I don't believe even DevExpress supports this feature either.
  23. Robert
    Robert avatar
    8 posts
    Member since:
    Mar 2008

    Posted 01 Nov 2012 Link to this post

    Does the ConstraintAutoHideArea property new to Q3 2012 have anything to do with this?

    I can't tell based on the description:

    "Implemented a property(ConstraintAutoHideArea) allowing the Panes to go outside the Docks boundaries"

  24. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 02 Nov 2012 Link to this post

    Hi Robert,

    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.

  25. Robert
    Robert avatar
    8 posts
    Member since:
    Mar 2008

    Posted 02 Nov 2012 Link to this post

    Thanks for the clarification.

    So I assume there are no firm plans to add any of the features discussed in this thread?
  26. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 07 Nov 2012 Link to this post

    Hi Robert,

    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.

  27. Jan
    Jan avatar
    4 posts
    Member since:
    Nov 2011

    Posted 13 Jun 2013 Link to this post

    It was promised to be present in Q2 2013 but it is not even scheduled yet as I see in PIT: http://www.telerik.com/support/pits.aspx#/details/Issue=2304

    Are there any plans to work on this in the next release?
  28. Robert
    Robert avatar
    8 posts
    Member since:
    Mar 2008

    Posted 13 Jun 2013 Link to this post

    Or, ever?
  29. Adrian
    Adrian avatar
    10 posts
    Member since:
    Jun 2013

    Posted 13 Jun 2013 Link to this post

    I also wait for this feature in our project.
  30. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 17 Jun 2013 Link to this post

    Hello Everybody,

    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.

  31. Adrian
    Adrian avatar
    10 posts
    Member since:
    Jun 2013

    Posted 03 Oct 2013 Link to this post

    Hi,

    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?
Back to Top
DevCraft banner