G'day

I've got a BO being maintained in a Devexpress grid. I'm saving the bo if required in the grid's BeforeLeaveRow event, and if the save causes a broken rule stoping the move off that row. My problem is that if I have a column with a sort on it and change a value in that column that will cause a broken rule, as soon as I click onto another row the sort takes effect before the BeforeLeaveRow event, whisking the broken row out from under me (similarly if I apply a sort to a different column if I already have a broken rule in the current row).

I've tried navigating in the grid to try to get back on the broken row, I've tried setting the BO's AutoNavigateToFirstBrokenRow, I've tried navigating and moving in the BO to the Broken row, all to no avail. Anyone have any ideas where I might have gone wrong, or what should work?

Peter

Sorts...they are always good for causing an issue   I am not familiar with the DevExpress grid off of the top of my head, but the first thing I would think to try would be to handle the SortChanged event (if one exists) on the grid.  This would at least inform you that the sort has changed.  You could then set the sort of the BO to the same value as the grid which would put the rows in the same order.

That would be the first thing that I would try.

Trent,

I thought about your advice and decided that sorting the BO the same as the grid would be too difficult given that the grid also does grouping and filtering, and it seemed too much to hope that I could get exactly the same ordering in the BO after several of these had been applied.

After a further day working on the problem I almost have a solution. Clicking on a new row in the grid fires a BeforeLeaveRow event followed by a FocusedRowChanged event. There are gridview methods that allow me to translate between rowhandles on the grid to rowindex in the BO. What I was doing in the BeforeLeaveRow was to save the BO and hence setting any broken rules, then if there was a broken rule setting e.allow in the event args to stop the row movement happening, and then if the first broken row isn't the current row attempting to change the Focused row onto it (which was not happening, and I'm assuming that it was because setting e.allow to false stopped any pending FocusedRowChanges). Anyway, moving this logic to the FocusedRowChanged event handler has allowed the focused row to be changed and I'm almost set. Still a few lose ends to tidy up and different scenarios to test.

Peter

Thanks for the info, Peter.  I am sure others will appreciate the input as well!