The issue is I want to allow the user the ability to shrink and stretch the width.
After having set the Resizable proerty to true, the docks can be resized smaller, but cannot be resized larger. Is this by design and if so, is there a workaround?
13 Answers, 1 is accepted
The docked RadDocks cannot be resized beyond the borders of the RadDockZone in which they are placed by design.
A possible approach in this case is to utilize the dock client-side events OnClientResizeStart and OnClientResizeEnd in order to temporarily set a bigger size of the RadDockZone when dock resizing starts and return its original size after the resizing is finished.
Greetings,
Slav
the Telerik team
I think the issue may be with the way the dockzone orientation is applied. I am using horizontal orientation to ensure smaller width docks can be rearranged on a single line and the overflow items go down vertically.
I'll look at the events you mentioned and check them out.
I have not been able to accomplish a suitable alternative using the events, so I decided to simply write my own resizing mechanism, however, the parent RadDock div seemingly will not accept the values I set. I can manually adjust the values in Firebug without issue, it shouldn't be this difficult to change the values programmatically.
This is the javascript that I am trying to use to manipulate the dock.
$(document).ready(function () { var i = 0; $('td.rdRight').mousedown(function (e) { e.preventDefault(); $(document).mousemove(function (e) { var itm = e.target.offsetParent.parentElement.id; $(itm).css('width', (e.layerX + 2).toString); }) }); $(document).mouseup(function (e) { $(document).unbind('mousemove'); }); });As you can see, I am waiting until the document is ready then attaching a mousedown event to the rdRight div. The event fires as expected, placing a temporary mousemove event.
The mousemove event fires as expected, the element is located, and the css value seemingly gets applied, but the control does not reflect the changes.
When the mouseup event fires, the mousemove event is removed to prevent problems elsewhere.
The strange thing is that this works as expected if applied to other divs, just not this one.
RadDock is a complex control with underlying API and specific rendering and its functionality depends on these elements, simply changing the CSS attributes to the wrapper element may achieve the required outcome for the moment but such approach may cause unexpected behaviors.
For your convenience I have prepared a sample using the ClientResizeStart and ClientResizeEnd events to achieve the described behavior:
<telerik:RadDockZone ID="zone1" runat="server" Width="600px" Height="400px" Orientation="Horizontal"> <telerik:RadDock ID="dock1" runat="server" Width="200px" Height="100px" Resizable="true" OnClientResizeStart="dockResizeStart" OnClientResizeEnd="dockResizeEnd"> </telerik:RadDock></telerik:RadDockZone><script type="text/javascript"> var zoneOrgWidth = 0; function dockResizeStart(dock, args) { var zone = $find("<%=zone1.ClientID %>"); zoneOrgWidth = $telerik.$(zone.get_element()).width(); $telerik.$(zone.get_element()).width("100%"); console.log(zoneOrgWidth); } function dockResizeEnd(dock, args) { var zone = $find("<%=zone1.ClientID %>"); $telerik.$(zone.get_element()).width(zoneOrgWidth); }</script>Could you please try it out and see if this is exactly what you need to achieve. If not, could you please be more specific on the issues with this approach.
Regards,
Dobromir
the Telerik team
Stepping through the telerik code is quite revealing though. The function _calculateFreeZoneSpace is returning a huge negative number in the neighborhood of -3850px
I am not quite sure why this is not working correctly on your side. Please take a look at the following video demonstrating this sample on my side and see if I am missing something.
http://screencast.com/t/wFTsCyOyCXGf
Kind regards,
Dobromir
the Telerik team
I realize now the problem is compounded by the fact that the container holding the dock zone is statically sized to fit inside a RadWindow. It is one of many controls being placed on the page.
I am testing an override for the dock control and it seems to work as expected, except I cannot get the dock to stop resizing at the container width. The function calculates the area of all the docks in the dock zone and reports back if there is enough room to make the dock wider.
This is the override I am using to report additional space in the dock zone:
function dockResizeStart(dock, args) { dock._caluclateZoneFreeSpace = function (c) { var e = $telerik.getContentSize(c.get_element()); var d = c.get_docks(); var a = 0; for (var f = 0; f < d.length; f++) { var g = d[f]._getBounds(); a += parseInt(g.height * g.width); } if (a < parseInt(e.width * e.height) && this._width < c.get_element().clientWidth) { e.width = c.get_element().clientWidth; } else { e.width = -1; } return e; } } I then restore the original function when the resizing ends, so as to not create problems with other functions
function dockResizeEnd(dock, args) { dock._caluclateZoneFreeSpace = function (c) { var e = $telerik.getContentSize(c.get_element()); var d = c.get_docks(); for (var f = 0; f < d.length; f++) { var g = d[f]._getBounds(); e.height -= g.height; e.width -= g.width; } return e; } }It allows me to resize the dock so long as there is room in the container to hold all of the docks. I have not yet included the functionality to calculate the height of the overflow, to ensure the docks don't exceed the parent container's height, but I have an idea on how to accomplish it.
The only problem with this approach is that so long as the dock is resizing, it is entirely possible to resize the control wider than the dock. If, however, the dock is stretched to the maximum width and stopped, then a new attempt to stretch the dock wider will fail, as it should. I also have an idea on how to manage this, but I have not done enough testing to implement it.
Perhaps you can provide guidance on the pros and cons of managing the resize in this manner.
1) CSS Rule to set max-width of the Dock to the width of the DockZone
2) CSS Rule to set min-width of Dock
3) Set initial width of each Dock to min-width value
4) Created each dock with the following values {Resizable=true; OnClientResizeStart="dockResizeStart"; OnclientResizeEnd="dockResizeEnd"}
5) Implemented override function as shown in my previous post
I still need to work out the logic to keep controls from being resized that would cause overflow outside the Y bounds of the dock zone, but I believe it can be done /mostly/ by assigning a row value to each dock (calculated from the offsetTop of the element) and returning the larger value of - room left in current row or width of any empty row.
Is there any particular reason why the default resize function will allow you to resize a dock larger than the remaining room in the container, unless you release the mouse button and try a second time?
Anyway, I think I can live with the results for now.
It is just too bad that a horizontal dock is not sized automatically based on the width of the content, (unless overridden of course) that would make dynamically created docks just a bit easier to implement, particularly for an application such as the one I am developing.
The default resizing functionality of RadDock should not allow you to resize a dock in order to make it larger than the available space in the dock zone. Is this the scenario you have in mind or I have misunderstood you?
Regards,
Slav
the Telerik team
The dock needs to be resizable up to the width of the dock zone in all cases except when the resizing of that specific dock will cause the docks to flow on another line vertically.
The problem with using vertical orientation is that the docks are generally oriented one per "row" in a vertical fashion and I would like to have more than one dock per "row" as the dock zone container is 2 to 3 times wider than the dock. If I choose horizontal orientation, the width of all the docks in the dock zone exceed the width of the dock zone, thus causing the docks to flow to additional rows and allows multiple docks on each row. However, this approach is flawed because for example, lets say the dock zone is 600px wide and I have two dock zones that default to row 0 with dock0 at 250px and dock1 at 300px. What I would like to be able to do is resize either of the docks an additional 50px larger so that the docks in row0 are the width of the dock zone. (dz=600px, d0=250px, d1=300px leaving 50px free)
Additionally, I would like to be able to resize any dock up to the width of the dock zone, for example resize d0 to 600px and force the remaining docks to reposition on the rows as if they would when originally rendered.
The whole problem come in with the way the caluclateZoneFreeSpace function returns the available space in the dock zone. If the the total width of the docks in a dock zone exceed the width of the dock zone, then no resizing larger is allowed, even if there is vertical space that can be utilized or if the dock zone is set to scroll vertically. For example, 4 docks in a horizontal dock zone that is 500px wide. Each dock is 300px wide causing 4 rows in the dock zone ... the width of the free space is returned as -700px (4 * 300px - 500px) despite it being quite obvious that there is an additional 200px available on each row.
Ideally, the width of any single dock should never be allowed to exceed the actual width of the dock zone and a dock should be able to be resized to whatever width is desired so long as it doesn't force the docks to change the row in which they are located.
The code I have provided above, like I said, it *almost* there ... a nice addition would be to allow a dock to be resized even if it causes a dock to go to another row, if either of two conditions are met. 1) There is vertical room for another dock row to fit at the bottom of the dock zone; OR 2) there is enough room on any subsequent row to allow resizing of a dock and not cause an additional row to be created. For example, docks in row0 are 600px and the last dock in row0 is 300px, but the total width of the docks in row1 is <=300px or there is vertical space to allow another row to be added at the bottom.
I know that is alot to digest, but I hope it was clear enough to understand.
Indeed, there is a problem with resizing the docks when there is more than one row in the horizontally oriented RadDockZone. I have brought this issue to the attention of our developers, although I cannot provide a firm estimate when a fix will be available. You can track the status of the problem, vote for it and comment it via the Feedback item that I logged.
I have updated your Telerik points as a token of gratitude for reporting this bug.
Regards,
Slav
the Telerik team
I have what I believe to be a very similar situation as yours, whereby I'm dynamically adding RadDocks to zones - except mine are in a vertical orientation, and I'd like the parent RadDockZones to expand vertically while I increase the Y dimension of the docks, within.
This thread has helped me get through some of my problems, but I'm still hitting snags. Did you ever achieve your goal, and would you mind posting your final solution/findings?
I appreciate your time and effort!
Kind Regards,
Aaron T. Jessen