GroupByRows and Locking ScrollBar

570

Sean K posted over 15 years ago

Hi All,

I have an UltraGrid bound to a BindingSource which is being updated via a backgroundworker. When my background process is completed, the following method is called:

try

{

UltraGridRow r = dgOrders.DisplayLayout.ActiveRow;

int firstVisible = dgOrders.ActiveRowScrollRegion.FirstRow.Index;

dgOrders.BeginUpdate();

dgOrders.SuspendLayout();

dgOrders.DataBind();

if (r != null)

{

dgOrders.ActiveRow = r;

dgOrders.ActiveRowScrollRegion.FirstRow = dgOrders.Rows[firstVisible];

}

dgOrders.ResumeLayout();

dgOrders.EndUpdate();

}

catch (Exception ex){}

What I'm aiming to do is to keep the current active row activated and to keep the scroll bars from shifting when the grid calls DataBind(). This works perfectly fine when I there are no GroupByRows, when there are GroupByRows the FirstRow property of the grids ActiveScrollRegion ALWAYS returns a GroupByRow (even if a normal UltragridRow is at the top of the visible portion of the grids display area). This makes is very difficult to determine where the first row of the scroll region should be set after the update.

Has anyone run into something similar when using GroupByRows?

Thanks,

Sean

Parents

469350

Suggested Answer
Offline Mike Saltzman posted over 15 years ago

Hi Sean,

I'm glad you got it working.

But FYI, binding the grid or any control to a data source that is being modified on another thread is an extremely dangerous thing to do.

Neither the WinGrid not the BindingManager are thread-safe. There are several detailed discussions of this on these forums, such as this one:

Work with a dataset bound to a grid on a separate thread - Infragistics Community
Cancel
Reply

Reject Answer

Cancel

Reply

570

Sean K posted over 15 years ago in reply to Mike Saltzman

Hey Mike, Thanks for the response. I've had success using the UltraGrid/BackgroundWorker combination by always making sure to use a lock/Monitor/Mutex in the BW DoWork event. This typically restricts access to the grid/datasource to a single thread (at least in my experience). Then when the BW finishes its job, the RunWorkerCompleted event should be fired on the UI thread so I would think it's OK to call the grid's DataBind method at that point. Am I missing something? I read the post you suggested and have used a similar approach (BeginInvoke, Invoke etc.) in tandem with a custom, thread-safe binding source and have also not noticed any issues w/ the grid syncing to the datasource.... Is there any other documentation discussing thread safety issues w/ the UltraGrid?
Cancel
Reply

Cancel

Children

469350

Offline Mike Saltzman posted over 15 years ago in reply to Sean K

Hi,

I don't claim to be an expert on threading. But my understanding of the issue goes something like this:

Suppose DoWork gets called on the BackgroundWorker thread and it begins to modify the data source.

Now, some operation occurs on the grid or the data source which requires it to loop through the rows on the UI Thread.

So the code on the UI thread checks the count of the rows collection to make sure it's greater than 0. It is, so it proceeds to attempt to access the first row.

But in between the checking of the count and the accessing of the first row, the background thread removes the row, leaving 0 rows.

This will cause an Exception on the UI Thread which will happen intermittently, seemingly at random, and be next to impossible to track down.

As far as I know, there is really no safe way to do this other than to disconnect the grid and any other bound controls from the data source before you attempt to make any changes to it on another thread.
Cancel
Reply

Cancel