The code below is what I did to partially solve this problem. DataAccess.DeleteRow is a method that deletes the row from the database and the dataset that is bound to the grid.
I thinki that if Inragistics spent more time making their existing code do what it should do, instead of adding features, we wouldn't need hacks like this.
void M3EditableGrid_BeforeRowsDeleted(object sender, BeforeRowsDeletedEventArgs e)
{
UltraGridRow[ rows = e.Rows;
if (rows.Length > 0 && RemoveButton != null)
foreach (UltraGridRow row in rows)
if (row.HasPrevSibling())
_previousRow = row.GetSibling(SiblingRow.Previous);
else
_previousRow = row.ParentRow;
DataAccess.DeleteRow(row, (DataSet)this.DataSource);
}
e.Cancel = true;
void M3EditableGrid_AfterRowsDeleted(object sender, EventArgs e)
if (_previousRow != null)
_previousRow.Activate();
UpdateButtons(); ;
this.Focus();
Hi,
howardw39 said:I thinki that if Inragistics spent more time making their existing code do what it should do, instead of adding features, we wouldn't need hacks like this.
The behavior you are descibing here isn't really controlled by the grid. The grid's ActiveRow stays in synch with the Current position of the DotNet CurrencyManager. So when you delete a row in the grid, the grid tells the BindingManager to delete the row. At this point, if the grid has no active row, it's because the CurrencyManager has no current row.
Theoretically, the grid could force a new ActiveRow after the delete, but it's not really obvious (to me, at least) that this would be the right thing to do. I can see how you might want a new active row, but this might not always be the case in every application. Suppose there is a large proces that occurs when a row is selected in he grid and you don't want it triggered right away?
It's a lot easier for you, the developer, to set a new active row after the delete takes place then it would be for you to stop the grid or CurrencyManager from activating a new row if you didn't want this behavior.
Even if we assume that you are right and that this is a bug, we can't change this behavor now without breaking existing functionality.
Of course, the solution would be to add a property to control this behavior so you don't have to write the code for it. You should probably submit this to Infragistics as a feature request.
Request a Feature or Component