A couple of our screens have more than one Xceed grid with a ScrollViewer.  When there are, for example, 20 rows, enough where the screen needs to be scrolled to see the end, when I click on one of the lower rows, it jumps the view to the top row (for that grid).  My focus is still where I clicked, and I can type even though I can't see where I'm typing.

Is this expected behavior?  Can I tell the ScrollViewer to not scroll just because I've clicked a row?

I tried intercepting a couple of events (such as an edit event for the grid and a scroll event for the ScrollViewer), but what I've tried doesn't seem to change the behavior.  (For instance, trying to un-do the scroll by forcing a scroll in the opposite direction didn't seem to work.  But when I told it to scroll to "home" (to the top of the screen) that did seem to work [also, ditto for the end], although that's not what I'm trying to do!)

If I just had one grid and nothing else, I wouldn't need the ScrollViewer, and the problem doesn't exist, so the problem does seem centered around the ScrollViewer.  If I remove it, I lose my scrollbar, of course, and cannot access much of the screen.

(I did a lot of Googling, and I didn't see anything about this specific issue.)

Thanks in advance! 

Gary 

While this thread below describes a different problem, I wonder if it is similar enough.   One problem is reliably determining that the scroll event was caused by an edit and not by using the scroll bar, which is one thing I ran into when I last looked at this, but at least I should be able to force the offset as described.

http://xceed.com/CS/forums/thread/13020.aspx

Gary

I found a solution -- catch the RequestBringIntoView event at a level beneath ScrollViewer and if the control is a grid, mark the event as handled.  So, ScrollViewer never sees this event, which is triggering it to set the focus to the grid (which always defaults to the first row).  The view doesn't change, so creating an event to move the view isn't necessary.  (It ended up being simpler than I thought it was going to be.)

This article isn't exactly the same problem I was having, but was helpful to illustrate how to handle this event:

 http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/bab3fb62-bf9e-4db6-854c-829bd2896319

Hope this helps someone else.

Gary