I've got a grid with:
The odd behavior I'm experiencing is that the row being added does indeed retain focus, however a new TemplateAddRow is being added and initialized incorrectly. The expected behavior is the same as when an update is triggered by trying to change the row (the row retains focus and the template add row is left unaffected)
Things I've tried:
Any ideas?
Hi,
Oh, okay, I misunderstood. You said the row was being added an initialized incorrectly. I thought you meant that there was some problem with the Initialization of the row, not that the addition of the row itself was incorrect.
The way it works is, when you have a TemplateAddRow, the row you see in the grid is not a real row. It does not exist in the data source.
When you click on that row, it's still not a real row. It becomes a real row once the user makes a change to any cell in the row. So once you begin to edit a TemplateAddRow, the grid calls AddNew on the BindingManager and the TemplateAddRow becomes an AddRow and a new TemplateAddRow is added to the grid.
Anyway, I created a sample based on what you described here and there are a couple of areas of confusion.
First, pressing Enter on the TemplateAddRow already causes it to be committed, so I did not need to add any KeyActionMappings.
Second, as I said, the TemplateAddRow is already there as soon as I make any changes to the existing TemplateAddRow. So when I press Enter and the row update is cancelled, the AddRow I was editing stay there. Since the row stays around and the grid is essentially still in a state where the user is editing the AddRow, the TemplateAddRow should stay just where it.
So I'm not really clear on what the problem is.
I'm attaching my sample here so you can try it out.
Interesting. I've taken your sample and modified it slightly to reproduce my problem:
Now if you run the application and add a row and try and commit by tabbing the behaviour is as expected. If however you press enter the template add row below is initialized.
I've attached the solution so you should be able to see this now.
I ran your sample and I get the results you describe. Somehow, the first row is getting committed when the DataErrorInfo is in play. I looked into this briefly, but I don't immediately see why this is happening. It's going to require some more thorough investigation. So I'm going to forward this thread over to Infragistics Developer Support and ask them to write this up for developer review.