Visual Studio 2010 introduced the concept of document windows which behave like a regular tool window. Implement the same functionality within RadDock.
using the RadDock component in a product that must support multiple montors. I see some mention of this in the support forums, but I would like to confirm with you that RadDock does support docking on multiple monitors with dragging of panes/panels between monitors and full serialization of the layout on multiple displays. Add support to move and maximize DocumentWindow and ToolWindow in multimonitor system.
RadDock should have ActiveMDIChild property which returns the currently activated mdi child. Resolution: Use the ActiveMDIChild property of the parent form.
When a floating window is hidden and RadDock layout is saved, the hidden window is saved in its Docked state and displayed as Docked when layout is loaded.
One should be able to drag and drop a ToolWindow to the ToolWindows area even if this ToolWindow is currently docked in the DocumentWindows area, similar to the VS2010 behavior.
Trying to Double-Click ToolWindow to dock it back on RadDock as a Tab... When you set a ToolWindow to only AllowedDockStates of Floating,TabbedDocument and Hidden, you lose the header double-click functionality of the toolwindow that pops the ToolWindow out as a floating window as well as pops it back in as a tabbed document. If you add AllowedDockState of Docked, the double-click functionality works. I am working with ToolWindows on a RadDock control and want them only represented as either Floating or TabbedDocuments with the ability to double-click a floating window caption and pop it back onto the RadDock control as a TabbedDocument. I got the double-click functionality to pop a floating window back in by using DockStateChanged and TransactionCommitment events. The less important one of double-clicking on a TabbedDocument header to pop it back out I have not yet done. I use the DockStateChanged event to fire when ToolWindows are set to floating and change the AllowedDockState of that window to use Docked. I use TransactionCommitment to change a ToolWindow's AllowedDockState to exclude Docked and programmatically change the DockState of the window to TabbedDocument. Is this the best approach or did I miss a simple property or something? I pasted the two methods below for your convenience. Resolution: In Q1 2014 (version 2014.1.226) we introduced an floating option for tabbed document which resolved this issue. Here is the link to the feedback item: http://feedback.telerik.com/Project/154/Feedback/Details/111942-improve-give-floating-option-for-tabbed-document
A nice addition to the existing save/load layout functionality of RadDock will be the possibility to save the AutoHideSize value.
support of Pin tab operation in DocumentContainer of RadDock
as magnetic behaviour I mean that when you move a window close to another window, the first window just snap to the other. The same behaviour is fine when you resize a window. The magnetic behaviour helps you to arrange floating windows into the screen, so people dont get crazy trying to align and resize all the floating windows around in the screen.
This feature request refers to introducing a new ToolWindow property which will allow setting individually text to the ToolWindow's Caption and Tab.
Would be useful to have the option to create the tab close button theme which depends on the states of the button's containing tab.
Currently, it is not possible to add any RadElement to a TabStripItem in DocumentTabStrip. Resolution: Use the static class RadDockEvents to subscribe to events before InitializeComponent
There should be a method which allows the user to host a Form in a HostWindow. This will come in handy when there is a save/load layout scenario. Resolution: Use the DockControl method to host a form. Here is the code snippet: Form form = new Form8(); this.radDock1.DockControl(form, Telerik.WinControls.UI.Docking.DockPosition.Left);
RadDock - implement BackgroundImage property.
A nice addition to the existing RadDock implementation for re-docking floating windows will be the ability to re-dock floating windows to documents if the previous state of the floating window was a document window.
A user should be able to scroll to a desired item (window) by selecting it from the overflow menu. Currently, the selected item is inserted at the first position and the order of items is changed.
I've discovered a behavioral issue with the tool-window when one of its containing control's data-binding is updated. I'm designing an application using the MVVM design pattern with a basic View and View-Model. The View is a form that contains a RadDock, ToolWindow containing a Label, and a Button to update the Label's Text; and data-binding setup to the ToolWindow's property "DockState" and a Label's property "Text". The View-Model contains the bound properties "ToolWindow1DockState" and "Label1Text", which implements INotifyPropertyChanged to update the respective controls; and a method used to update Label1's text. After I click "Auto-hide" on ToolWindow1 and click the "Change Text" button, I'm expecting ToolWindow1 to remain in the Auto-hide state. Instead, ToolWindow1 is placed in the Docked state.
The user should be allowed to modify the default behavior of floating windows and decide whether they should be owned by the main Form or they should act like normal Forms - with Minimize/Maximize options and appearing in the System's Taskbar.