I have a RadDockLayout with two RadDockZones, one zone is static with a single RadDock control, the other RadDockZone is designed to be dynamic allowing the user to rearrange the orientation of the RadDock controls inside the RadDockZone. There are only two RadDock controls in the second zone. The orientation of the second zone is Horizontal.
One RadDock control width is set to 67% the other is set to 33% to fill 100% of the width of the RadDockZone. The height is set client-side to fill the available screen (these docks contain RadGrids with lots of data and scroll off the screen).
If the user attempts to move the RadDock control on the right side, to the left side, it is possible that the dock orientation changes and the controls become oriented vertically.
Also when re-orienting the RadDock controls to horizontal, they are no longer the width specified by the style. It is as if there is a hidden element taking up a percentage of the RadDockZone.
The only changes I am making to the controls is a client-side script that adjusts the height of the first child container in the RadDock control to force the RadDock height to fill the remaining portion of the screen.
Further testing indicates that some client-side scripting from the telerik client-model changes the width of the controls from a dynamic width using percentages, to a hard-coded width. Once the dock is dragged out of its location, the fixed width forces the dock to flow into another row, despite the DockZone being set to horizontal, because once the dock overflows, the scroll-bar appears and reduces the width of the parent container, thus restricting the ability to re-dock in a horizontal manner. Once this happens, it is nearly impossible to get the dock to re-orient itself in the correct location without a refresh of the page from the server.
One RadDock control width is set to 67% the other is set to 33% to fill 100% of the width of the RadDockZone. The height is set client-side to fill the available screen (these docks contain RadGrids with lots of data and scroll off the screen).
If the user attempts to move the RadDock control on the right side, to the left side, it is possible that the dock orientation changes and the controls become oriented vertically.
Also when re-orienting the RadDock controls to horizontal, they are no longer the width specified by the style. It is as if there is a hidden element taking up a percentage of the RadDockZone.
The only changes I am making to the controls is a client-side script that adjusts the height of the first child container in the RadDock control to force the RadDock height to fill the remaining portion of the screen.
Further testing indicates that some client-side scripting from the telerik client-model changes the width of the controls from a dynamic width using percentages, to a hard-coded width. Once the dock is dragged out of its location, the fixed width forces the dock to flow into another row, despite the DockZone being set to horizontal, because once the dock overflows, the scroll-bar appears and reduces the width of the parent container, thus restricting the ability to re-dock in a horizontal manner. Once this happens, it is nearly impossible to get the dock to re-orient itself in the correct location without a refresh of the page from the server.
1 Answer, 1 is accepted
0
Keith
Top achievements
Rank 2
Rank 2
answered on 20 Apr 2013, 04:09 PM
I was finally able to resolve this issue by doing the following:
1) Change the ClientIdMode of a child control to Static, this way the parent control is always named in a predictable manner.
2) Create a CSS rule
3) Set the DockZone attribute FitDocks to False
I am still working on trying to stop the DockZone from resizing when a dock control is dragged, but that is a minor issue.
1) Change the ClientIdMode of a child control to Static, this way the parent control is always named in a predictable manner.
2) Create a CSS rule
#dock_control_ID_1{ width: 67% !important; } #dock_control_ID_2{ width: 33% !important; }3) Set the DockZone attribute FitDocks to False
I am still working on trying to stop the DockZone from resizing when a dock control is dragged, but that is a minor issue.