I'm using an UltraWinGrid to display messages coming in at regular intervals. The message structure is defined in a config file read at run time, and my program adds columns to the UltraWinGrid as needed to display strings, numbers, and booleans.
Because of the fluid structure of the data, I can't use any kind of binding to a collection of objects - the object structure would have to change on the fly. Instead I add/lookup rows to an UltraDataSource and iterate over each cell to update the values inside.
Even though the number of rows and the data in them mostly stay the same, every time my update method runs the vertical scroll position on the grid is reset to the top. I tried storing the ActiveRowScrollRegion.ScrollPosition, but even at the end of my method the value appears to be unchanged - the change to scroll position must be an asynchronous action.
I also captured the AfterRowRegionScrollChange event, but it only gets called when I manually move the scroll bar, not when the scroll bar is just bouncing to the top of the grid.
Any suggestions or thoughts?
Hello John,
Thank you for contacting Infragistics.
The UltraGrid should maintain its scroll position when you add or update rows, as long as you don't change the value of the DataSource property of the grid.
If you can provide me with a sample project that reproduces the issue, I'll look at it and see why it's not behaving as it should.
The grid's scroll position will be lost any time the layout gets reset. This will happen if you set the grid's DataSource / DataMember (or call SetDataBinding).
It can also happen if your DataSource sends a Reset notification.
If can also occur if, for some reason, the BindingManager sets the Current position to the first row.
So something you are doing in your code is almost-certainly causing one of these things to happen.
The scroll position is probably getting updated the next time the grid paints. So you could, in theory, store the position before you begin your operation, and then restore it inside the grid's Paint event. But this is a little tricky. You only want to do it when you have a stored position. And you need to prevent recursion, since setting the position will likely cause the Paint event to fire again.
My advice would be to try to find out what you are doing that is causing this to occur and stop doing it. That will be a much more reliable fix.