Hi,
So I am here again, questioning the behavior a bit... thanks again on help with the TemplateAddRow vs. DataTable.NewRow() methods of adding the row. I have switched to the TemplateAddRow method for adding rows so that I can get the BeforeRowUpdate to fire. However, after pounding on it a while, I found that the cancel feature removes everything the user added... so when I validate the row, and one column is in error, I do not cancel the update. This leaves the grid in a precarious state. The user can move to another row, they can move to other controls or grids but really, we want them back on the row editing the value that is not right.
I have tried a number of things to pull them back but nothing seems to work. And the other concern I have, is that even if I can get them back on the row, I found if they change nothing, the BeforeRowUpdate will not fire even though I am in a bad state when they again try to leave the row. Basically, once they have committed to adding a row, I want to insure they get past validation before I will let them save or cancel. Perhaps my approach to this is wrong... perhaps there is a way to control them they way I want...
I was wondering why setting the ActiveCell of the grid to an item on this row, does not put the user's focus on the cell. It seems like it ought to.
From the BeforeRowUpdate...
grid1.ActiveCell = e.Row.Cells["FieldName"];
Any thoughts? Thanks,
Kent
Hi Kent,
Thank you for posting in our forums.
Maybe the BeforeExitEditMode event will be most useful for you in this case. If the user has entered invalid data, or no data at all, you can cancel the event and the cell will remain in edit mode until a valid input is entered.
Setting just the ActiveCell, will only activate the cell, but it won’t enter edit mode. The following method will bring the active cell into edit mode:
ultraGrid1.PerformAction(UltraGridAction.EnterEditMode);
I have attached a sample, which demonstrates the BeforeExitEditMode approach.
Let me know if you have any additional questions.
Thank you for the demo app...
This solves all but one problem. If you recall, prior to this and another similar thread about the BeforeRowUpdate event, I was saving my user input via a DataTable.NewRow(). I am not sure why, but the binding to the DataTable is quite different when using the TemplateAddRow.
Using the TemplateAddRow feature with the events as suggested, I finally call the save (SQL) to my new row of data during the AfterRowUpdate event. What I have found for the new data row is that sometimes it saves and sometimes it does not. I cannot seem to put a reason on it but debugging the AfterRowUpdate, I sometimes find that the underlying data table, (that I send to my middle tier) does not have the new row added. Other times it does. It was only saving about 50/50, initially, I added an "AcceptChanges()" to the DataTable which saves about 70% of the time. But I need 100%.
Do you have any thoughts why the binding to the DataSource DataTable would not complete by the time AfterRowUpdate fires? Is there a way to insure that the editing is done and binding completes?
Thanks again,
Hello Kent,
I am just checking about the progress of this issue. Let me know if you need my further assistance on this issue.
Thank you for using Infragistics Components.
Thank you for the reply.
I have tried to reproduce the described behavior and for me the count of the rows in the data table and the rows in the grid in the AfterRowUpdate is always identical. Does that happen when you try to commit a row which wasn’t modified by the user (the default values are used)? Have you changed the UpdateMode property of the grid? Can you isolate this behavior in a separate sample?
Thank you for your collaboration.
I am looking forward to hearing from you.