Hi Bill,

wugates said:

How would the DataSource send a Reset notification?

The DataSource will send a Reset in response to some action that may change a lot of rows or the entire data structure. For example, if you are using a DataSet and you use a DataAdapter.Fill to fill a table, this will cause a Reset. There are others, of course.

wugates said:

 I created a BeforeSortChange handler and set a breakpoint in it but the only code in the call stack was Infragistics and System.Windows.Forms.

If you could post the call stack so I can see where it's coming from it might give us a clue.

wugates said:

Regarding taking the grid out of the tab control I was thinking of doing that, i.e. progressively dismantling the app until the problem can be isolated.  Then once isolated I should be able to create a sample project and send it to you.  I will pursue this.

That's probably the most reliable way to see for certain exactly what's happening. If I can reproduce it here, I can track it down for sure. :)

Hi Mike,

I am using Infragistics version 2012.1.  I looked through the code looking for something that would make it reposition, but didn't find anything, i.e. I looked at all occurrences of ActiveRow, FirstRow, RowScrollRegion and ScrolLRowIntoView.  How would the DataSource send a Reset notification?  Nothing is going on with the DataSource as far as I can tell.  I created a BeforeSortChange handler and set a breakpoint in it but the only code in the call stack was Infragistics and System.Windows.Forms.

I tried setting a breakpoint in the BeforeRowRegionScroll event handler but everything in the call stack is just Infragistics and System.Windows.Forms.

Regarding taking the grid out of the tab control I was thinking of doing that, i.e. progressively dismantling the app until the problem can be isolated.  Then once isolated I should be able to create a sample project and send it to you.  I will pursue this.

Thanks,

Bill

Hi,

I've watched the video again and the problem seems to be very specific to a series of steps. I've tried this out in a very simple case with a grid in a Tab Control and three levels of grouping like it appears you have here, but I am unable to reproduce the issue.

My best guess is that this was a bug in an older version of the grid. What version of the grid are you using? I did my testing with 15.1 and the latest service release.

Another possibility is that there's something in your code that is causing the grid to re-position. The obvious way to do that would be to set the ActiveRow, set the FirstRow on the RowScrollRegion, or call ScrollRowIntoView. It could also happen if the grid is re-building the rows collection, which it would do if the grid's DataSource sends a Reset notification. The obvious place to look for these kinds of things would be in the BeforeSortChange or AfterSortChange events, which will fire when you click the column header.

Also, you specifically mentioned that the grid is inside a tab control. That seems unlikely to be a factor, but since you mentioned it - is there some reason you think that's related? Have you tried taking the grid out of the tab control?

If none of that helps, it might be a good idea to put a breakpoint in the BeforeRowRegionScroll event of the grid. Disable the breakpoint, then get the grid into a state where the problem will occur when you click on the column header and enable it and then click the header. Frankly, this is kind've a grasping-at-straws approach, because the call stack will probably show that the scroll started with the grid's Paint event, which doesn't really tell us much, but on the off chance that it's something else, it might be worthwhile and it's something very easy to try. 

If that's still no good, we will probably need a small sample project demonstrating the behavior so we can debug it and check it out.

Hello,

Thank you for providing a video. I'll be attempting to reproduce this today. If you happen to have a sample demonstrating this I'd greatly appreciate it. Let me know if you have any additional questions.