Hi Steve,

If you just want to commit the changes to the current row in the grid, then all you have to do is call Update on the row or UpdateData on the grid.

The grid will, by default, automatically commit the changes when you leave the row or lose focus on the grid. But if you click on something else on the form, such as a toolbar button, that does not take focus, then you need to make sure you manually call one of the above-mentioned methods to commit the changes.

Hi Mike ... The mapping does work. What we are looking for is to have the grid and the form update when the user exits a grid cell or form control.  We know that the CommitRow happens when you click on another row. However in our app we don't want to have to force the user to click on another row and then click back on the row they updated just to see the changes display. For the mapping, when the user exits the cell or control with what ever key we've mapped to do a CommitRow it updates the display the same way as if you have clicked on another row. We were just wonderinig if using the mapping is necesary or if there was an equivalent way (i.e. a property) in the grid and in a form control to have it do a CommitRow when the user tabs out or clicks out of the cell/control they are updating. Using the mapping seems a bit forced and thought maybe there is something in the grid functionality that would do this for us without implementing the mapping code ...

Steve

Since I don't know what the original issue is or what it's cause was, I'm afraid I don't have much of a guess on the matter.

Moving from one row to another in the grid already commits the row to the underlying DataSource of the grid and that will happen before the CommitRow maping gets called, since you are adding your new mapping to the end of the collection. So I really can't see how your mapping could be having any effect at all. It will not even get triggered until the grid has already moved the focus to the next row.

Are you sure that this mapping actually does something? If so, then I must be wrong about some part of this. Either that or committing a row with no changes is somehow forcing the BindingManager to do some sort of refresh or update. But that seems very strange and unlikely.

You could try trapping the BeforePerformAction event on the grid and trap for actions like NextRowByTab and PrevRowByTab and then call PerformAction(CommitRow) or grid.ActiveRow.Update in there to see if that has any effect.

Hi Mike,

We are still working through this issue and have had some success using BindingSource and BindingContext to sync updates between the form and the grid. I do have a question about something we are doing in regards to getting updates made in the grid to appear in the form, and whether you feel this is the most expedient way of handling that situation.

In order to get the form controls (i.e. textboxes, etc) to update when the grid is updated, we use KeyActionMapping on the grid that does a CommitRow action when you press a certain key such as Enter or Tab. Here is what the code looks like:

this.ultraGrid1.KeyActionMappings.Add( new GridKeyActionMapping(Keys.Tab,UltraGridAction.CommitRow,0,UltraGridState.InEdit ,0,0));

The question is why do you think the CommitRow action necessary in order for the update done in the grid to simultaneously appear in the related form control? Are there any disadvantages to using CommitRow in this regard? Is there a grid property that we can use to do basically what this KeyActionMapping/CommitRow code is doing? Our concern is that we are creating code for something that the grid might already do on it's own, and we'd like to avoid that and implement the grid functionality properly. ... If there is a property that controls this that we can use then hopefully that same property exists for the form controls as well, as we'd like to have the same solution no matter which direction the updates are going (form to grid or grid to form). Let me know what you think ...

Thank you!

Hi,

I tried your sample and I get the same results, even using the latest version of NetAdvantage.

However, this does not appear to be an issue with the Infragistics controls. I tried replacing the UltraWinGrid with the Microsoft DataGridView and the UltraTextEditors with the Microsoft TextBox controls and I get the same results. Just to be extra careful, I remove all Infragistics controls from the project and I still get the same results.

So I don't know why this is happening, but it appears to be a bug or some strange quirk in the DotNet BindingManager.

I'm attaching my modified sample here so you can check it out. I recommend reporting the problem to Microsoft or checking a more general MS or DataBinding forum. I can't believe that no one else has ever encountered a similar problem before.