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
I'm having some problems coming up with a workaround for this problem. In the example shown above the event BeforeRowsDeleted is being handled, however in my case this event isn't triggered. I'm deleting the rows directly from the datasource, which doesn't seem to trigger this event. I think in the example above the row is being deleted directly from the grid perhaps? Anyhow in my case the row is(correctly) being removed from the grid, but isn't triggering this event. Is there another event that I can handle if a row is being REMOVED? Or if not is there a way to implement a workaround such that when a row is removed the previously selected row(or even just the last row in the listbox) is automatically activated?
Thanks!
Something that has worked well so far for us is to make all changes in the grid, once it is filled from the data source. The grid then automatically handles updating the data source.
I agree that it would be nice to have a grid property that automatically selects the next row after a row is deleted. This should be designed to work whether the row was deleted in the grid and then the change was propagated to the data source, or the other way around.
Fixed it in a very similar way to howardw. Just instead of getting the before and after notification from the ultragrid(which isn't triggered when modifying the datasource directly) I just used these same notifications directly from the datasource. Otherwise the code is very similar. It's just somewhat indirect.