Skip Navigation LinksHome / Community & Support / Developer Productivity Tools Forums / Silverlight > Docking > Nexted RadDocking Controls

Answered Nexted RadDocking Controls

Feed from this thread
  • Jonathan avatar

    Posted on Aug 20, 2009 (permalink)

    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

    Reply

  • Answer Miroslav Nedyalkov Miroslav Nedyalkov admin's avatar

    Posted on Aug 21, 2009 (permalink)

    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.

    Reply

  • Tim avatar

    Posted on Apr 23, 2010 (permalink)

    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.

    Reply

  • Miroslav Nedyalkov Miroslav Nedyalkov admin's avatar

    Posted on Apr 23, 2010 (permalink)

    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.

    Reply

  • Tim avatar

    Posted on May 7, 2010 (permalink)

    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?

    Reply

  • Miroslav Nedyalkov Miroslav Nedyalkov admin's avatar

    Posted on May 11, 2010 (permalink)

    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.

    Reply

  • Tim avatar

    Posted on May 11, 2010 (permalink)

    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.

    Reply

  • Tim avatar

    Posted on May 11, 2010 (permalink)

    Let me make it slightly more clear.  I don't think there should be nested RadDocking's allowed inside a RadPane, only RadDocumentPanes.

    Reply

  • Miroslav Nedyalkov Miroslav Nedyalkov admin's avatar

    Posted on May 13, 2010 (permalink)

    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.

    Reply

  • David avatar

    Posted on Feb 14, 2011 (permalink)

    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.

    Reply

  • Tim avatar

    Posted on Feb 15, 2011 (permalink)

    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!

    Reply

  • David avatar

    Posted on Feb 15, 2011 (permalink)

    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.

    Reply

  • Andrew avatar

    Posted on Jun 11, 2011 (permalink)

    I definitely need this feature as well.

    Reply

  • Andrew avatar

    Posted on Jan 10, 2012 (permalink)

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

    Reply

  • Miroslav Nedyalkov Miroslav Nedyalkov admin's avatar

    Posted on Jan 13, 2012 (permalink)

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

    Reply

  • Tim avatar

    Posted on Jan 16, 2012 (permalink)

    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.

    Reply

  • Miroslav Nedyalkov Miroslav Nedyalkov admin's avatar

    Posted on Jan 17, 2012 (permalink)

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

    Reply

  • David avatar

    Posted on Jan 18, 2012 (permalink)

    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

    Reply

  • Tim avatar

    Posted on Jan 24, 2012 (permalink)

    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.

    Reply

  • Jan avatar

    Posted on May 11, 2012 (permalink)

    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.

    Reply

  • Tim avatar

    Posted on May 11, 2012 (permalink)

    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.

    Reply

Back to Top

Skip Navigation LinksHome / Community & Support / Developer Productivity Tools Forums / Silverlight > Docking > Nexted RadDocking Controls
Related resources for "Nexted RadDocking Controls"

Silverlight Docking Features  |  Documentation  |  Demos  |  Telerik TV  |  Self-Paced Trainer  ]