Pressing Enter to Commit Edit moves to the row below

[Guy Inwhitenorth]

Hello,

After upgrading to Q1 2010, I've noticed that pressing enter while editing a cell commits the edit, then moves focus to the row below, putting the cell in that row into edit mode. I can certainly see why this is desirable behaviour for some applications, however, for ours it is not. Can never please everyone :). We would like to keep the behaviour from the previous version, which would commit the edit, end edit mode in the cell, and leave focus on that cell.

Is there a way to achieve that behaviour in the new version? We need to use the new version of the grid as it contains other fixes we need.

Thanks

[Milan]

Hi Guy Inwhitenorth,

We have recently introduced new extensibility point allowing you to overwrite or just modify how RadGridView handles keyboard commands. I have prepared a sample application that demonstrates how this extensibility points can be used to bring back some of the old keyboard handling.

Kind regards,
Milan
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

[Robin Das]

 .... why did the bahaviour need to change ????.  Bug fixes are one thing but this is off the wall. 

The reason it worries me is that as applications grow I won't be able to upgrade without sending the whole app back through testing not just for bugs, that would be reasonable, but for changes in behaviour too !.

In future stop arsing about with things ... add functionality yes but doing things like this costs us a lot of time and money.  Having put a lot of code in to get thing working I have to put another load of code in to get it working again and so on and so on .... LOB apps are trust through stability.  This is not stability its a headache.

[Nedyalko Nikolov]

Hello Robin Das,

Indeed we changed keyboard behavior, and we are really sorry for the inconvenience caused. I'll try to clarify a little bit why we do that.

We introduced this improvement to the keyboard navigation, since this feature was requested by a lot of our customers. The improvement in fact is the possibility to change the behavior of any key which normally RadGridView handles. We thought a lot which mode to become default and we decide that current mode is the most common case. My colleague Milan post an example is this forum thread how to override keyboard behavior which you could find helpful.

All the best,
Nedyalko Nikolov
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

[Lynne]

Would you please provide an example of keeping focus on a grid row after a CommitEdit?  

I'm using your custom KeyboardCommandProvider example and I can get the focus to move to the first row, the last row, or an explicitly focused row, but not the new row entered and committed.

Also, when trying to find out what something is, in this case what .MoveFirst does, this is not particularly helpful documentation: 

• Field Value
  The move first command. 

Do you provide any documentation that explains what the various Move<N> commands are supposed to do when applied in the context of a RadGridView editing operation?

Thanks.

[Maya]

Hi Lynne,

Generally, MoveFirst command will move focus to the first focusable element in tab order - if you are in a row, the focus will be set to the first cell. 
Considering the exact behavior, could you clarify a bit on it ? Do you want to keep the focus in the grid once you insert new item ? 

Kind regards,
Maya
the Telerik team

[Lynne]

After edits occur in a row, whether new or existing, I want to focus to remain on the row, but with no cells in active editing mode.

I can get this to work, sometimes, but the behavior of MoveFirst seems inconsistent, or perhaps it's based on some variable I don't yet understand.  It would be very helpful to have all the commands in RadGridViewCommands fully documented, with explanations.  The existing "MoveFirst means move first" is not only not helpful, it's annoying and causes me to waste time searching the web for product documentation that should be included with a product, IMO.  A lot of your API-level documentation (at least for WPF) has similar problems, and I was wondering when we could expect a fix?

For instance, my questions in this thread would have been entirely unnecessary if the documentation actually explained what the commands do in the scope of their use within a RadGridView.  Is there other documentation I'm missing?

[Maya]

Hi Lynne,

Indeed, you are right, the commands are not documented in such great details. We do have an aritcle included for them, but as it turns out, not all of the supported ones are listed.
Nevertheless, we will update the documentation so that it provides more information on them.
Please excuse us for the inconvenience.  

Greetings,
Maya
the Telerik team