9 Answers, 1 is accepted
Thank you for writing.
Requested functionality is not available out of the box. But you can implement it by changing GridBehavior with a custom one and overriding ProcessPageUp/Down event handlers. Please, review the code-block below as an example:
Hope this helps. Write me back if you have any additional questions.
the Telerik team
1. Add a built-in Method to change the CurrentTemplate. Like I said before, adding a Select Next/Previous Template/View/Tab to the Method GridNavigator Class seems to be a logical place since it already has them for Columns and Rows.
2. Add options to simply "turn on" the Ctrl-Page Up and Ctrl-Page Down keys (or at least allow specification of the keys desired) for this purpose since: a) keyboard switching of Tabs seem to be a pretty common feature, b) Ctrl-Page Up and Ctrl-Page Down keys seem to be the most common keys for said feature, and c) the workaround is too complex for such a common feature (I mean inheriting a Class and overriding Methods which aren't even documented as existing much less overrideable. Come on, are you serious? ;)).
Thank you for getting back to me.
I will discuss your suggestion with our developers, but you have to keep in mind that if we put this feature in our to-do list it will not be with a high priority since there is a way to implement it. Also, we believe that changing grid behavior is a very common scenario when speaking for developing a custom end users requirements. Also it offers a vary large flexibility and it can handle a wide range of special behavior such as this case. Meanwhile we are constantly working on improving our documentation and probably we will include this case as an example in our KB library.
the Telerik team
1. Re. "not be with a high priority since there is a way to implement it": I'm sure there's a "way to (manually) implement" many of your already existing "features" without abandoning your tools . That doesn't mean those features shouldn't have been added or even added with a "high priority". The point is not just whether it can be done at all, but whether it can be done significantly easier / better.
2. Re. "changing grid behavior is a very common scenario when speaking for developing a custom end users requirements" and "it offers a vary large flexibility and it can handle a wide range of special behavior such as this case": I'm not saying it isn't or doesn't. I'm just saying that in this case it should not be necessary for users to do so because this is, from what I've seen, a very common (i.e. not "custom" and not "special") feature of Tab-style Controls in Windows Desktop Apps and the tools used to implement them, not the least of which are Microsoft's apps and their .Net tools. Because of that obvious de facto standard, I propose that It isn't significantly more "custom" than requiring the Up and Down Arrow Keys to move to the previous and next Row or the Ctrl-Home and Ctrl-End keys to go to the top and bottom of the Grid, the latter of which was in another post I made and which also could be "implemented" by users by "changing grid behavior". In that case, although the manual "implementation" was still non-trivial (requiring overriding of an undocumented Method), it was actually a much, much simpler implementation and I was still promised with certainty that it would be added as a feature in an "upcoming release" and I was also given points for making the suggestion. I'm not even asking that these keys be "required" to work this way. I'm just asking that you add a simple option ("simple" meaning a documented Property setting or Method call) to: a) turn on the proposed behavior for these keys, b) specify the keys the user wishes to implement this behavior and/or c) make it trivial to manually "implement" by adding something like "Select Next/Previous Template/View/Tab (call it what you want) Methods to the GridNavigator Class which seems to be a logical place since it already has them for Columns and Rows".
3. In several other posts where I've made "feature requests", I was given points even though Telerik only promised that it would "consider" adding the "feature", much less add it with a "high priority".
Thanks for the feedback.
It has always been our priority to simplify the work that our customers need to do in order to accomplish a specific task. However, as with everything in life, we need to prioritize what features to include next. For example, would you prefer to have an impractical and chunky UI by having multiple scrollbars in hierarchy mode, or would you rather prefer just one scrollbar? Is this feature more important than having CTRL+TAB for navigating to the previous / next Tab? What if you compare the CTRL+TAB feature with having a faster and better performing grid, with less memory consumption? Which one is more important?
Although our gut tells us that some features are more important than others, we have always let our users decide what we should implement next. So, if the discussion about having CTRL+TAB picks up, we will surely up its priority in our ToDo list.
I see that no points were added for the feature request, so I did that now.
As to the undocumented methods, I scheduled these for documentation, including the ones in your other post (RE: CTRL+TAB).
the Telerik team
2. a. I still can't believe that ya'll won't recognize that this is a a very common (i.e. not "custom" and not "special") feature of Tab-style Controls in Windows Desktop Apps and the tools used to implement them. What more examples do you need than Microsoft? Also, aren't you supposed to be "better" than Microsoft, otherwise, we could just use .Net and not buy Telerik. Being "better" means not only adding features, but also not losing features. b. Thank you for scheduling the docs.
3. Thank you for the points.
2. Believe it or not, yes, we do consider this feature to not be so common, not because we have a workaround, but because we have gotten only a couple requests for it over 2 years. As I said, we let our users decide what we should implement next and usually they set our priorities. I will be happy to bump the priority of this request in case we get more requests for it.
Thank you for the understanding.
the Telerik team
a. If you or even Microsoft used that method in your initial design, I bet many of your and Microsoft's already existing features would not have made the cut. These very same keys might not have made the cut for Microsoft if they had used that method prior to adding them.
b. Regardless of how many of your users have bothered to explicitly request it, the point is Microsoft already has it now, so to be "better", then by definition, you have to have it too or at least a better alternative which you don't. By "alternative", I mean for example, you might implement the behavior with different keys you thought would be "easier" for end-users, but even then, you still should have an easy option to match the defacto standard set by Microsoft (i.e. backwards user-expectation compatibility, i.e. a "Classic" mode or ".Net" mode or how Word and Excel had mode options that emulated their competitors' U.I.'s), "easy" meaning a simple Enumerated Property setting.
c. The other point, like I said, is that this is so "easy" to add (or should be), that it shouldn't require this much discussion. I mean you already have the code written (in this Forum thread) for crying out loud. You probably could've added it, tested it and documented it in less time than it took to respond to this thread.
d. Also, y'all added the Ctrl-Home/ Ctrl-End keys I suggested for top / bottom of grid and I referred to in my Oct. 29 post in this thread. I hadn't seen any other requests for those keys at least in the RadGridView Forum.