so is the final answer that I am on my own...or do any of the support engineers have any final suggestions?  This post has gotten very quiet since my last 2 posts...

Oh and one other problem with the initializeRow event is that after a user does a sort or a filter and then they decide to make a row edit, that row gets updated based upon the wrong index/visible index/listindex reference.  But ironically...the internal grid array reference keeps the correct location just fine.  So yeah... i am pretty much stuck with writing my own array unless there is someway to expose that property.  Cheers...

Mike -

It really depends on what you mean by "sorted", as I allow for column sort which I do NOT want saved as well as row filters which I do NOT want saved.  Manual ordering by the user can only be done when the rows are NOT sorted by column or filtered.  So my users open the list, and hypothetically, they decide to sort on column A.  Not a problem, they just will not be able to drag and drop rows or move rows up or down until they turn the column sort off, which resets the order of the rows.  So lets say they do that... they turn sort on, maybe do a filter too, and then find the row they want, pin it to the top and then turn the sort off and clear the filter... all of the rows go back to where they were originally (because the grid IS keeping an internal reference somewhere), but the pinned row is at the top.  So then they decide to drag and drop some rows to another location.  Those new row locations need to be maintained even though there is a pinned row, but currently the pinned row shows index/visible index as 0 which would not be correct.  OK ... I have done the updating through InitializeRow event... but that gets all "goobered up" (technical term) if a row is pinned.  So ultimately, I am left with 2 options that I am understanding:

1)  no row ordering is allowed if rows are pinned/sorted/filtered

or

2) create my own row index array and synchronize it based on what is going on (which would allow my users to retrieve a list, sort the list, save the list using the sorted row order, and then move rows around for any final tweaking they may want to do). 

I was just hoping that there was some way to access the internal row index that is kept separate from the display and the original listindex.  I am thinking that the "other" way of thinking about it is that Infragistics did not expose that property and I will have to duplicate the effort or limit my users on what they can do (and we all have the experience in telling users the reason they cannot do things is due to "just because").  Let me know if I have gotten any of my facts wrong... I have much appreciated all of your feedback!

Hi,

I'm still not exactly clear on what you are trying to get here.

It sounds like what you want is that you want to maintain the sorted order of the rows in the grid, but you do NOT want to maintain the order of row that are fixed. Is that right?

If that's the case, the sorting should be no problem. When you sort the grid, the Index property of the rows will return the visible order.

So the only problem is with fixed rows, because fixing a row sets it's index and you don't want to use that index.

To be honest, I'm not sure exactly what the grid does when you fix a row and then unfix that row. It must be internally maintaining some sort of index so that it knows where to put that row when you unfix it. But if you fix a row, then sort the grid, then unfix the row, what happens? Does that row go back to it's original index? Or does it simply get re-sorted into it's new proper position?

If it's just placed into it's proper sort position, then it would be possible for you to determine where that row should go.

If it's placed back to the same index it came from, then storing the Index in the BeforeRowFixedStateChanged would be the way to go - because I am certain that the grid does not expose whatever internal index it is storing.

It seems to me that it might be easier for you to approach this problem from another angle. Why not simply unfix the rows right before you go to save your data, and then re-fix those same rows after the operation is complete?

Hmmm... I am not being very clear I guess in the row index that I am looking for, so I will explain why each of the index listed and why BeforeRowFixedStateChanged is such a bad idea.  First, I will be more clear as to the problem I am solving.  I pull 100 items from the database.  Users can "pin/unpin", sort, and filter those rows.  These actions ARE NOT saved in the database, so the rows must keep their original display order values.  Now the users can also reorder the rows to a specific order.  Now the new re-ordered list display order IS saved in the database.  Clearly the grid has a property (maybe it is not exposed) that is maintaining its original position  but it is not one of the index that you have referenced.

Index - this is the index being displayed - useless for what I am needing when it is pinned/sorted/filtered

ListIndex - this is the original order pulled from the database and does not change even when the Row.Move function is called, so again it is useless if the user moves a row up or down.

VisibleIndex - this is the index in the collection - useless for storing in the database when it is pinned/sorted/filtered

BeforeRowFixedStateChanged- big whoop... not helpful except for pinning, and even then, not very helpful since I need to deal with sorted and filtered conditions

In summary... sorry for being so vague before, but now that I "think" I have explained the problem specifically, I am really hoping that the index property I am looking for is exposed for me to reference.  If not, then why not?  I can only shake my head in disbelief to think I would have to write my own synchronized array to manage what is clearly already managed by the grid.

But since you are a infragistics staffer - I am hoping you have the magic answers  :D