We've all been there. I'm just glad we were able to help you get this resolved. :)

*sigh* there comes a time in every programmer's life when the most seemingly difficult problem is solved by the most obvious answer.  You are right, I already have that unbound column tracking display order, I can just do my synchronization by checking the status flags of the grid (e.g. sorted/filtered/pinned) and then do the appropriate update from there.  To say that I feel dumb on fixating on finding a grid property would be an understatement.  Thank you both for the feedback.  Solution found!

I'm still not sure I understand exactly what you want to achieve. Let me take another shot at it, though.

It seems like what you want is for the users to be able to manually move a row to another position explicitly. I assume you have set up Drag and Drop in your grid to allow this. Or maybe you have buttons for moving rows up and down.

If that's the case, then any sorting the user did would completely negate this, of course. So it sounds like what you are saying is that the user has to turn off any sorting in order to do this.

Is that right?

If that's the case, then why don't you simply disallow the moving of rows while there are rows that are pinned, just as you do when there is sorting in play? It seems to me that there's no difference. If you can't allow the user to move rows while sorting is in play, then you can't allow it while pinning is in play, either and for the same reason - it creates ambiguity.

Even if you could determine the "real" index while a row is pinned, there would still be a problem, because the user could pin a row and them move some other unpinned row. The pinned row's position is now ambiguous since the order of the rows changed.

I suppose that maybe what you want is to store the positions whenever the grid is in a good state. So if the user moves a row and then sorts the grid, you want to store the positions that the rows were in before the sort took place and maintain those, regardless of whatever happens afterward. If that's what you want, then I think you could do this using an unbound column in the grid and storing the index of the row at certain key points. You could use BeforeSortChange, for example, to store the index of every row whenever there is no sorting currently in place, but when sorting is about to occur. Similarly, you could update the index in the BeforeRowFixedStateChanged event. In fact, all you really have to do is call a single method from both of these events. This method would check to see if there is any sorted or any fixed rows currently in place and if not, update the unbound column with the current Index of the row.

Hristo -

Thanks for the feedback and insight.  After calling the row move, I am then calling the grid.updatedata and then grid.Rows.Refresh(RefreshRow.FireInitializeRow, True) so that all of the rows that are affected get called.  In my testing I do not see any changes to the ListIndex.  I am using unique row markers, but I do not see how that will help unless I run my own synchronized array, and then I was going to handle the rowID and the row position in the array, but if I am doing something wrong with the ListIndex, let me know.  I would really prefer to use what is already in the grid control than to write extra synchronization code. 

So it looks like maybe the ListIndex is not changing by the row.move, you may want to check that functionality since it does not change in any of my testing. 

"I call the row move using this code"

grid.Rows.Move(aRow, aRow.Index + 1)

grid.UpdateData()

grid.Rows.Refresh(RefreshRow.FireInitializeRow, True)

"I check changes from within the initializerow method using this code"

if e.Row.Cells("DisplayOrder").Value <> e.Row.ListIndex then

{update the displayorder and the database}

end if

but the listindex is not changing on row.move.  let me know if you see something different in your code.

BIG Thanks!