User (Old forums)MemberApril 12, 2005 at 8:50 amPost count: 23064
Just emailed this to support. Thought I’d try here as well:
I get an exception when updating the value of a cell. This happens in a multithreaded application and the thread updating the value is not the main UI thread. I suspect this is the reason. Can you verify if this is supported?
If the threading is indeed the problem, can you think of a workaround? I really need to use threads to collect the data that is to be displayed in the grid. Rows are not added from the threads, just cell values are updated.
The exception does not happen often, but at times it will show up. This is the end of the call stack of the exception:
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
at System.Collections.ArrayList.RemoveAt(Int32 index)
at System.Collections.ArrayList.Remove(Object obj)
at Xceed.Grid.DataManager.ResumeDataRowModifiedEvent(DataRow dataRow)
at Xceed.Grid.DataCell.SetCurrentValue(Object value)
at Xceed.Grid.DataCell.SetValue(Object value)
at Xceed.Grid.Cell.set_Value(Object value)
Imported from legacy forums. Posted by Tomas (had 800 views)User (Old forums)MemberApril 22, 2005 at 12:38 pmPost count: 23064
I also encountered this problem while building a multithreaded app using Xceed Grids to display the data. The problem occurs because your are modifying a user interface control from a thread other than the thread that owns its handle (in this case the main UI thread).
This is not possibile in windows forms. Even if the grid is bound to a datasource, and you modify the data source on a background thread then fire a list changed event to the grid you still (eventually) encounter this error or a variation of it.
The solution we settled on was doing as much of the processing as possible on the background thread and then doing the actual modification (via a databound collection) on the main UI thread using Invoke. The following links are quite good for this sort of thing. They are the three parts of a “Safe, Simple Multithreading in Windows Forms” set o f articles.
It does seem strange, as I would have thought that merely modifying the values would not interfere, but moving the updates onto the main UI thread solved this problem for us. And, thankfully, at the end of the day the performance hit was not significant, although it did make the code a bit more complex!
Hope this helps,
Imported from legacy forums. Posted by David (had 3003 views)
- You must be logged in to reply to this topic.