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.

Hi Bill,

Sorry, that's the wrong event. I meant BeforeRowRegionScroll, actually. But if that's not firing, then maybe you could try AfterRowActivate and post the call stack from there. To be honest, it probably won't help, but it might give us an idea and it's a lot quicker than creating a small sample project so it might be worth a shot.

Hi Mike,

OnAfterRowActivate isn't firing when the scroll to the top problem occurs when clicking the column header.  I will pursue isolation of the problem.

Thanks,

Bill

Hi Bill,

Okay, it looks like the sample is the only way go then. I will leave the case open and check back with you in a few days if I don't hear from you before then. :)

Hi Bill,

I'm just following up again. Were you able to reproduce the issue in a sample?

Hi Mike,

Not yet.  I've been sidetracked with some other responsibilities.  I may need to turn this over to another group in my company.

Regards,

Bill

Hi Bill,

Well, that makes sense, I suppose. Store the row and then restore it's position. Thanks for the update.

It would still be nice to know why it's happening in the first place, though.

Hi Mike,

Our staff discovered a clever workaround fix for this which is to implement BeforeSortChange and AfterSortChange handlers to reposition the scroll bar:

void OnBeforeSortChange(object sender, BeforeSortChangeEventArgs e)

{

  //remember current scroll position
  _scrollPosition = this.ActiveRowScrollRegion.ScrollPosition;
}

void OnAfterSortChange(object sender, BandEventArgs e)
{

  //restore remembered scroll position
  this.ActiveRowScrollRegion.ScrollPosition = _scrollPosition;
}

Regards,

Bill

Hi Mike,

Let's close it for now because I don't know when the other group will be able to get to it.

Thanks,

Bill

Hi Bill,

Do you have any kind of estimate as to when you will be ready to revisit this issue? If you know when, I can put the case on hold and check back with you then. Otherwise, it might be better to just close this came and you or someone at your company can open a new one when you have time. :)