Hey Telerik,
So, this is a really bold venture of mine. I would be completely willing to add the code to the Knowledge Base afterwards.
I would like to move the property "Orientation" from the RadSplitter control to the RadSplitBar. Do you believe that, with a lot of blood, sweat, and tears, one would be able to override all the dependent methods and make this a reality? I would love some information on where to start.
I could go into great detail about why this would be beneficial to me, but suffice to say that I have an extremely large amount of nested controls. These controls resize a lot, and the code for how to calculate resizes has become horrendous. Moving this functionality would allow me to delete hundreds upon hundreds of lines of code which currently exist to bridge the gap.
Looking forward to hearing a response to this.
Thanks,
Sean
So, this is a really bold venture of mine. I would be completely willing to add the code to the Knowledge Base afterwards.
I would like to move the property "Orientation" from the RadSplitter control to the RadSplitBar. Do you believe that, with a lot of blood, sweat, and tears, one would be able to override all the dependent methods and make this a reality? I would love some information on where to start.
I could go into great detail about why this would be beneficial to me, but suffice to say that I have an extremely large amount of nested controls. These controls resize a lot, and the code for how to calculate resizes has become horrendous. Moving this functionality would allow me to delete hundreds upon hundreds of lines of code which currently exist to bridge the gap.
Looking forward to hearing a response to this.
Thanks,
Sean
1 Answer, 1 is accepted
0
Hello Sean,
Such a feature, although looking quite tempting, is extremely difficult, if not impossible to accomplish with the current ideology and implementation of the RadSplitter control.
The RadSplitter's Orientation property is more closely related to the RadPanes, rather than the RadSplitbar. The reason for this is the way the panes are rendered with HTML. Having a splitbar is just another abstraction of a pane, rather than a way to define spaces in the control. What you wish to accomplish is to shift the focus away from the panes themselves to the splitbars. This is a new ideology of rendering and managing the RadSplitter control.
Moreover, purely theoretically speaking, having just the Orientation property makes arranging undetermined. Imaging two SplitBars - one with Horizontal and one with Vertical orientation. Just so defined, there are two ways to position these splitbars in the splitter. The problem tends to increase complexity exponentially, as another splitbar would result in 2x3 = 6 ways to position them. Therefore a more precise positioning needs to be implemented, which will result in a completely different way of implementing the splitter controls.
Virtually, such an endeavor will result in implementing a new control that resembles the behavior of the RadSplitter, but utilized a different setup approach.
Unfortunately I cannot tell you where to start such a thing from as it is very complicated. Still if I were to start such a thing, I would start from the new methods to be used and provide wrappers on top of the current RadSplitter such that the new functionality is working using the old API.
I am not sure if my remarks are clear enough or make any sense. Nevertheless such an approach to implementing a splitter is interesting and it will be interesting to see to what extend it will be superior to the current one.
Best wishes,
Niko
the Telerik team
Such a feature, although looking quite tempting, is extremely difficult, if not impossible to accomplish with the current ideology and implementation of the RadSplitter control.
The RadSplitter's Orientation property is more closely related to the RadPanes, rather than the RadSplitbar. The reason for this is the way the panes are rendered with HTML. Having a splitbar is just another abstraction of a pane, rather than a way to define spaces in the control. What you wish to accomplish is to shift the focus away from the panes themselves to the splitbars. This is a new ideology of rendering and managing the RadSplitter control.
Moreover, purely theoretically speaking, having just the Orientation property makes arranging undetermined. Imaging two SplitBars - one with Horizontal and one with Vertical orientation. Just so defined, there are two ways to position these splitbars in the splitter. The problem tends to increase complexity exponentially, as another splitbar would result in 2x3 = 6 ways to position them. Therefore a more precise positioning needs to be implemented, which will result in a completely different way of implementing the splitter controls.
Virtually, such an endeavor will result in implementing a new control that resembles the behavior of the RadSplitter, but utilized a different setup approach.
Unfortunately I cannot tell you where to start such a thing from as it is very complicated. Still if I were to start such a thing, I would start from the new methods to be used and provide wrappers on top of the current RadSplitter such that the new functionality is working using the old API.
I am not sure if my remarks are clear enough or make any sense. Nevertheless such an approach to implementing a splitter is interesting and it will be interesting to see to what extend it will be superior to the current one.
Best wishes,
Niko
the Telerik team
If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the RadControls for ASP.NET AJAX, subscribe to their blog feed now