Change to Different Sibling ChildGridViewTemplate Programmatically in RadGridView

[Tom Chien]

I'm trying to implement Ctrl-Page Up / Ctrl-Page Down keys to go to the previous / next Tab (aka Sibling ChildGridViewTemplate) in a RadGridView with Tabbed Child View like what is supported in .Net's TabControl and in Tabs in Microsoft Office apps.  I figure I'd have to set the GridBehavior Property to my class that overrides the ProcessKey Function.  Beyond that I'm at a loss.  The GridNavigator Class doesn't have a Select Next/Previous Template/View/Tab method like it does for Columns and Rows.  The GridViewTemplate's IsCurrent Property is Read-Only.

[Martin Vasilev]

Hi Tom Chien,

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:

class CustomGridBehavior : BaseGridBehavior
{
    GridDetailViewCellElement element;

    protected override bool ProcessPageDownKey(KeyEventArgs keys)
    {
        if (keys.Control)
        {
            if (this.GridControl.CurrentCell != null)
            {
                RadElement parent = this.GridControl.CurrentCell.Parent;

                while (parent != null)
                {
                    if (parent is GridDetailViewCellElement)
                    {
                        break;
                    }
                    parent = ((RadElement)parent).Parent;
                }

                this.element = parent as GridDetailViewCellElement;
            }
            if (this.element != null)
            {
                this.SelectNextTab(element.TabStripElement);
                return true;
            }
        }

        return base.ProcessPageDownKey(keys);
    }

    protected override bool ProcessPageUpKey(KeyEventArgs keys)
    {
        if (keys.Control)
        {
            if (this.GridControl.CurrentCell != null)
            {
                RadElement parent = this.GridControl.CurrentCell.Parent;

                while (parent != null)
                {
                    if (parent is GridDetailViewCellElement)
                    {
                        break;
                    }
                    parent = ((RadElement)parent).Parent;
                }

                this.element = parent as GridDetailViewCellElement;
            }
            if (this.element != null)
            {
                this.SelectPreviousTab(element.TabStripElement);
                return true;
            }
        }
        return base.ProcessPageUpKey(keys);
    }

    bool SelectNextTab(RadTabStripElement tabStrip)
    {
        if (tabStrip.Items.Count == 0)
        {
            return false;
        }
        int index = tabStrip.Items.IndexOf((RadItem)tabStrip.SelectedTab);
        if (index < 0)
        {
            tabStrip.SelectedTab = tabStrip.Items[0];
        }
        else if (index < tabStrip.Items.Count - 1)
        {
            index++;
            tabStrip.SelectedTab = tabStrip.Items[index];
        }
        else
        {
            return false;
        }
        return true;
    }

    bool SelectPreviousTab(RadTabStripElement tabStrip)
    {
        if (tabStrip.Items.Count == 0)
        {
            return false;
        }
        int index = tabStrip.Items.IndexOf((RadItem)tabStrip.SelectedTab);
        if (index <= 0)
        {
            tabStrip.SelectedTab = tabStrip.Items[0];
        }
        else
        {
            index--;
            tabStrip.SelectedTab = tabStrip.Items[index];
        }

        return true;
    }

}

Hope this helps. Write me back if you have any additional questions.

Best wishes,
Martin Vasilev
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.

[Tom Chien]

Wow!  Thanks for the quick response on such a complex workaround!  Works great!  I would've never known to do all that even if I knew such methods could be overridden or even existed to begin with.  I guess that's why tool vendors don't document what methods can be overridden.  We'd get into too much trouble just like end-users would if we documented all file format elements, command-line switches and config file settings. ;)

[Tom Chien]

Like I said, your workaround works great and thanks again for the quick response, but after further review, since this is such a common feature for Tab-type controls,  I'd like to make the following "fea-ture re-quests" (hint, hint ;)):

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? ;)).

Thanks.

[Martin Vasilev]

Hello Tom Chien,

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.

Kind regards,
Martin Vasilev
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.

[Tom Chien]

Ok, I think this calls for a "WhaaaaTTTT?!?"  ;)

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".

http://www.telerik.com/community/forums/winforms/gridview/top-bottom-of-grid-keyboard-shortcuts-in-gridview.aspx

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".

[Vassil Petev]

Hi Tom Chien,

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).
 

Sincerely yours,
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.

[Tom Chien]

1. Ok.  The importance relative to other feature requests was not the reason you gave (in your Oct 29 post) for why it would not be a high priority" if it even gets added to the to-do list.  The reason you gave was simply that "there is a way to implement it".  Obviously, it's not as important as something like combining the Vertical Scroll Bars.  I wasn't saying that it was.  However, often features that have much less, but still significant, impact could be moved up in priority simply because they are so easy to add that taking the time to add them does not significantly delay the higher impact features.  I believe this is one of those features.

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.

[Vassil Petev]

All valid points, Tom, thanks for the feedback.

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.


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.

[Tom Chien]

2. I understand the user-requests method of prioritizing new features / fixes.  However:

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.