I'd like to make a "feature request" to add an option to allow multiple Tabs (GridViewTemplates) at the MasterGridViewTemplate (Root) Level. I know this can be done by combining a TabControl or RadTabStrip with separate RadGridViews (or even having a 0-Row "dummy" MasterGridViewTemplate), but adding this feature would make it significantly easier for the developer and end-user.
Telerik WinForms 2009Q3 Beta (2009.2.9.1016) / 2009Q2 (2009.2.9.729), VB, VS 2005 (v8.0.50727.762 SP.050727-7600), .Net 2.0 (2.0.50727), XP SP3, 3GB, 2.99GHZ, Core2Duo.
Telerik WinForms 2009Q3 Beta (2009.2.9.1016) / 2009Q2 (2009.2.9.729), VB, VS 2005 (v8.0.50727.762 SP.050727-7600), .Net 2.0 (2.0.50727), XP SP3, 3GB, 2.99GHZ, Core2Duo.
5 Answers, 1 is accepted
0
Hi Tom,
As you said this can be easily implemented by using a tab strip, so we are unwilling to add more complexity to RadGridView. Nevertheless, we appreciate your feedback. If you have any other ideas, please share them with us.
Best wishes,
Jack
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
As you said this can be easily implemented by using a tab strip, so we are unwilling to add more complexity to RadGridView. Nevertheless, we appreciate your feedback. If you have any other ideas, please share them with us.
Best wishes,
Jack
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
0
Tom Chien
Top achievements
Rank 1
Rank 1
answered on 04 Nov 2009, 03:33 PM
1. Yes, I said it can be done using the TabControl or RadTabStrip, but no, I did not say that I thought it could be "easily" done using those Controls. Regardless, of whether Telerik, me or bunch of other developers think it could be "easily" done using those Controls, my point was that it can be done "significantly easiER" if RadGridView supported that option. Separate RadGridViews means duplicate code for all the RadGridView option settings, Event Handlers, Class Overrides that would be shared if it could be done with one RadGridView, not to mention that we'd have to implement separate SaveLayout and LoadLayout calls for each Grid and the U.I. and storage organization that goes along with that.
The point is not whether something can be done via existing methods, but whether it can be done "significantly easier". It the point were the latter, then you, Telerik, all developers and lots of people in many industries whose primary job it is to make things "easier" would be out of a job / business. There's almost always a way to do things in a different but more difficult / expensive way. Conversely, there's almost always a way that it could be done "easier".
2. Regarding adding "more complexity to RadGridView", you could make this an "option" like I was requesting so only developers who want it have to deal with it. As for internal structure, you could implement it internally such that if "option" is "on", it would simply suppress the MasterGridViewTemplate from displaying and make it have one dummy Row that's always expanded. That way you don't have to start out with an array of ChildGridViewTemplates vs. the MasterGridViewTemplate as the Root which I agree would be significantly changing and adding "complexity" to RadGridView.
The point is not whether something can be done via existing methods, but whether it can be done "significantly easier". It the point were the latter, then you, Telerik, all developers and lots of people in many industries whose primary job it is to make things "easier" would be out of a job / business. There's almost always a way to do things in a different but more difficult / expensive way. Conversely, there's almost always a way that it could be done "easier".
2. Regarding adding "more complexity to RadGridView", you could make this an "option" like I was requesting so only developers who want it have to deal with it. As for internal structure, you could implement it internally such that if "option" is "on", it would simply suppress the MasterGridViewTemplate from displaying and make it have one dummy Row that's always expanded. That way you don't have to start out with an array of ChildGridViewTemplates vs. the MasterGridViewTemplate as the Root which I agree would be significantly changing and adding "complexity" to RadGridView.
0
Hi Tom,
Thank you for writing me back.
I understand your point and I agree that we should strive to make things easier.
It seems that my words came out wrong. All that I wanted to say is that the specified scenario is more easily implemented with the tabstrip, rather than with our current GridView design. If we build it in the grid, we will need to do a major refactoring of our internal data and UI structure, which means that a rather simple implementation on your end becomes a rather lengthy implementation on our end. Taking into account that no other customer has required the same functionality, we doubt that spending time on this request will be of so much benefit to our clients.
I nevertheless logged this as a feature request and if more people require the same, we will add it in our plans. I have updated your Telerik points for the suggestion.
Thank you for your understanding.
Regards,
Vassil
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
Thank you for writing me back.
I understand your point and I agree that we should strive to make things easier.
It seems that my words came out wrong. All that I wanted to say is that the specified scenario is more easily implemented with the tabstrip, rather than with our current GridView design. If we build it in the grid, we will need to do a major refactoring of our internal data and UI structure, which means that a rather simple implementation on your end becomes a rather lengthy implementation on our end. Taking into account that no other customer has required the same functionality, we doubt that spending time on this request will be of so much benefit to our clients.
I nevertheless logged this as a feature request and if more people require the same, we will add it in our plans. I have updated your Telerik points for the suggestion.
Thank you for your understanding.
Regards,
Vassil
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
0
Tom Chien
Top achievements
Rank 1
Rank 1
answered on 06 Nov 2009, 07:19 PM
Ok.
Re. "scenario is more easily implemented with the tabstrip, rather than with our current GridView design": That's "more easily" for Telerik not for Telerik's users. Usually to make things "easier" for the customer / user means making things "harder" for the vendor / developer (Telerik being the vendor and developers that use Telerik being the customers in this case). Doing the hard stuff for our customers is what we get paid for. A car's transmission is "more easily" implemented (by the manufacturer) as a manual vs. automatic, but it's not not easier for the buyers of the car to use.
Re. "need to do a major refactoring of our internal data and UI structure": So...are y'all saying that even my suggestion adding an "option" to use a hidden MasterGridViewTemplate with a single hidden, always expanded dummy Row still requires the "need to do a major refactoring of our internal data and UI structure"? Or perhaps, you think you'd have to / would rather replace MasterGridViewTemplate with an array of ChildGridViewTemplates? Actually, even if you did the latter, you'd still need something like a MasterGridViewTemplate to store all the Properties that apply to / default all the ones in the ChildGridViewTemplates.
Re. "scenario is more easily implemented with the tabstrip, rather than with our current GridView design": That's "more easily" for Telerik not for Telerik's users. Usually to make things "easier" for the customer / user means making things "harder" for the vendor / developer (Telerik being the vendor and developers that use Telerik being the customers in this case). Doing the hard stuff for our customers is what we get paid for. A car's transmission is "more easily" implemented (by the manufacturer) as a manual vs. automatic, but it's not not easier for the buyers of the car to use.
Re. "need to do a major refactoring of our internal data and UI structure": So...are y'all saying that even my suggestion adding an "option" to use a hidden MasterGridViewTemplate with a single hidden, always expanded dummy Row still requires the "need to do a major refactoring of our internal data and UI structure"? Or perhaps, you think you'd have to / would rather replace MasterGridViewTemplate with an array of ChildGridViewTemplates? Actually, even if you did the latter, you'd still need something like a MasterGridViewTemplate to store all the Properties that apply to / default all the ones in the ChildGridViewTemplates.
0
Tom, we are afraid things are not that simple - if it were, we would have already provided it. FYI, we also prefer to have a nice and stable feature, rather than a quick "patch up".
Guys,
would you like Telerik to add the option for having Multiple Tabs at the MasterGridViewTemplate Level? The more opinions we get, the higher the chance that we will implement it sooner.
Thanks.
Kind regards,
Vassil
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
Guys,
would you like Telerik to add the option for having Multiple Tabs at the MasterGridViewTemplate Level? The more opinions we get, the higher the chance that we will implement it sooner.
Thanks.
Kind regards,
Vassil
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.