Is it possible to emulate the AddNewRow behavior of Microsoft's WinForms DataGridView? This is the most intuitive DataGrid behavior I've come across and is pretty much the best way of doing fast data entry for LOB applications.

To achieve this, KeyboardNavigation.TabNavigation needs to cycle within the grid. Currently, navigation cycles within the row. Is there a way to change this so that tabbing at the end of a row moves to the next row?

If so ... (InsertionRow in TableView.Footers)

When a user enters some data in an InsertionRow, a new empty InsertionRow should be added below. That way there is always an InsertionRow to navigate to. If the user presses escape to cancel the row, it is deleted leaving a single empty InsertionRow and the process repeats.

Currently, I can't see how fast data-entry can work. When the user has finished editing in the InsertionRow, she has to click in the row above in order to commit the row and get a new InsertionRow. The alternative of pressing 'Enter' is fine but fails if you are in a multiline TextBox (AcceptsReturn) and is still not as visual and intuitive as having the next row there to tab into. Also, at the moment hitting enter to commit the row leaves the user in the same cell of the new InsertionRow. It would be better if the current cell was moved to the first (editable) cell in the row.

Is there any way to emulate this behavior at the moment? Is it something you plan on adding? It's an important feature and would make the DataGrid much nicer to use for fast data entry.

Thanks
Michael

Hi Michael,

The Insertion behavior as you indicated is not supported in the DataGridControl. There is currently no workaround or ways to emulate this behavior.

I have noted your suggestion in our feature request list. We will post back in this thread if there are any news concerning feature request.

---

Marc Laroche
Software Developer
Xceed Software Inc.

I don’t suffer from insanity, I enjoy every minute of it. - Unknown

I've just started looking at your DataGridControl and I must say; I am a bit surprised that the insertion behaviour described above wasnt part of the core design requirements for the DataGridControl.

Any application that requires lots of adding of records, ie invoicing, will be a bit troublesome.


It's almost as if adding records was an 'after thought', if you know what I mean.

Has anyone managed to 'fake' this behaviour?

Jack, I'm also shocked to find that it is not built-in behaviour to be able to press tab on the last cell and have that navigate to a new insertion row. I'd very interested to see how the grid is actually being used out there for fast data entry - if at all.

I'll re-ask your question just in case something has come up in the last month. Has anyone faked this behaviour?

Steve

I have to echo the sentiment here (including being "shocked"). Fast, efficient keyboard-based data entry seems to have been an afterthought. It's made more glaring considering the immense visual flair of the WPF DataGrid. Your data will burst forth from the screen, sparkle, and dance before you, but you can't add a new row by tabbing off the end of a table.

The only workaround I know of is to use Xceed's .NET Grid instead. The process is still "hacky," but it is possible.

Certain fundamental grid behavior (such as mimicking Excel data entry [e.g., Enter moves down, Shift+Enter moves up], tabbing to the next row from the last cell of a row, and the capability of tabbing "beyond" the last row to add a new one), in my opinion, would be best supported as behavioral "primitives" that can be independently enabled/disabled via properties. Such common behaviors can be time-consuming and sometimes impossible to hack in.

Of note: No matter how "easy" a hacked-in behavior may at first seem, there are almost always corner-case issues you have to contend with when they are not natively supported: For example, when grid end-users use fixed columns, it can greatly complicate the code necessary to maintain consistency with an overridden cell-navigation behavior.

This apparent oversight notwithstanding, the support I've received from the Xceed staff has been excellent so far, and that is reassuring.

Can someone please tell me if this behaviour has been updated in version 3.1 of the wpf grid?

 I have sold my client on using xceed instead of MS, but keyboard navigation is mandatory for this application.  If I cant create a new row after tabbing away from the insertion row; then I cant use the Xceed grid.

Currently I have added an PreviewKeyUp event on the last cell of the insertion row, to end editing; so i just need to know how to then move the focus to the next insertion row.

 

thanks.

Did you get a response on this?

Bringing this up again with the team now.

---

Odi Kosmatos
VP, R&D, Xceed

Any support for this in 3.1?

I started using DataGridControl few weeks ago and I've noticed some of simple features like this that is availabe in older technology missing. This feature is requried by many of us. 

I need to have some official response to this behaviour.

To elaborate more: 

The behaviour I need is: as soon as I type something in the InsertionRow, without losing focus, the record is already created in the ItemSource.

So when they click on a button outside of the grid, let say "Save", the data entered in the insertion row is recognized.

 Currently, the user has to enter values in the InsertionRow, and then either hit "Enter" key or Mouse click on another Row to commit changes to the ItemSource which the Grid is bound to.

  

Hi Fred,

You could check when the focus is moved from the InsertionRow or InsertionCell to a location outside the grid and call the InsertionRow's EndEdit method at that moment. The LostFocus event may be too late, so you will need to find an event that is raised sooner.

---

Diane Lafontaine
Technical Support / Technical Support Team Lead
Xceed Software Inc.

The official word is that to accomodate the kind of requests we've seen in this thread, we're going to have to rework areas of the datagrid's code that are high-risk for introducing new focus and navigation bugs. That means we won't want to do it for a service pack or while finishing up a major update. So we'll have to consider it as a project to start with for v3.4, with lots of testing, etc. V3.2 is being released next week, v3.3 in August, and v3.4 comes up after that, so it can't be ready before that. Short story: It's going to take a while.

---

Odi Kosmatos
VP, R&D, Xceed

Thanks for the official reply.  Hopefully when you do this navigation overhaul, you can give us several options for the different scenarios:

1. Inserting a lot of new data.  This should be done with the Tab and Enter keys, and the Enter key should take you back to the first InsertionCell by default, but is programattically changable (the first InsertionCell may be bound to an ID that is sometimes generated by the DB).

2. Modifying a lot of data.  Again, the (excel) standard of using Tab and Enter key for navigation should work here.  If I'm changing a lot of cells in a particular column or a pattern of columns, and I'm consistently hitting return in a particular cell and arrowing to certain cell in a particular column, the grid should start to pick up on this and take me to the next row's cell that correlates to the column that I have been starting at.

I would recommend that you try to match Excel as much as possible in these navigation techniques, as that is where the bulk of the end-users learn to do data-entry.

Finally, I must admit my surprise (with the rest of the people in this thread) that this grid is one of the most advanced WPF grids, but still doesn't have a decent and streamlined way of doing data entry.  I understand that a lot of typical usage is to view data in many different ways, and the Xceed WPF grid is extremely helpful in this regard.  But its not a data entry grid.

I'm definetely considering pulling all new data entry functionality from the inside my Xceed grid, and creating some kind of WPF overlay or my own "insertion row" above the Xceed grid.

Agree with Ryan.  We need similar kind of functionality where users want to do extensive data input to the order of 10k-20k rows sometimes.