We recently upgraded from 7.3 to 11.2 and randomly get exceptions - one of them occured on the following line as indicated by FAILS ON THIS LINE below.
This grid method contains DataTable search results for existing values entered on a form - if found, it is supposed to move the matching rows to the top of the grid and changes their appearance.I was wondering - we do not define Infragistics.Win.UltraWinGrid.UltraGridOverride.FixedRowStyle within our code - does it need to be? The rows have always been highlighted on the top of the grid.
Any ideas how to fix this - or safe way to block it?I found references to using BeginInvoke(new FixedRowDelegate(createFixedRow), e.Row), but this is not a Summary row and this is not a threaded app - and multiple rows could potentially become fixed/highlighted.
Thanks,Todd
Code:
private void FixCurrentRows() {
try {
if (this.ResultsUltraGrid.Rows != null&& (m_CurrentId != Guid.Empty || m_CurrentServiceRequestId != Guid.Empty)) {
foreach (UltraGridRow row in this.ResultsUltraGrid.Rows) {// Fix the Current matching row to the top of the grid when Searching for an Existing individual
if (this.ResultsUltraGrid.Text == "Potential Duplicate Requests"&& m_CurrentServiceRequestId != Guid.Empty && row.Cells.Exists("ServiceRequestId")&& (Guid)row.Cells["ServiceRequestId"].Value == m_CurrentServiceRequestId) {
row.Fixed = true; // FAILS ON THIS LINE
row.Appearance.BackColor =
Color.Yellow;row.Appearance.BackColor2 = Color.Goldenrod;row.Appearance.BackGradientStyle = GradientStyle.GlassBottom50Bright;break; // Exit the loop since we found the current service request
}else
if(m_CurrentId != Guid.Empty&& row.Cells.Exists("UserId")&& (Guid)row.Cells["UserId"].Value == m_CurrentId) {
row.Fixed = true;
row.Appearance.BackColor = Color.Yellow;row.Appearance.BackColor2 = Color.Goldenrod;row.Appearance.BackGradientStyle = GradientStyle.GlassBottom50Bright;
}
}catch (Exception ex) {Error.LogException(ex);}
Exception information:
Additional Information: Exception: System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.Parameter name: index at Infragistics.Shared.SparseArray.Insert(Int32 index, Object item) at Infragistics.Win.UltraWinGrid.RowsCollection.Move(UltraGridRow row, Int32 newIndex, Boolean forceDirtyPrimaryMetrics) at Infragistics.Win.UltraWinGrid.RowsCollection.MoveFixedRowsToProperLocation() at Infragistics.Win.UltraWinGrid.FixedRowsCollection.VerifyFixedRows(Boolean verifyScrollCount) at Infragistics.Win.UltraWinGrid.FixedRowsCollection.IndexOf(Object obj) at Infragistics.Shared.DisposableObjectCollectionBase.Contains(Object obj) at Infragistics.Win.UltraWinGrid.UltraGridRow.get_Fixed() at Infragistics.Win.UltraWinGrid.UltraGridRow.set_Fixed(Boolean value) at UI.WindowsForms.GeneralForms.SearchForm.FixCurrentRows() in d:\Sources\UI.WindowsForms\GeneralForms\SearchForm.cs:line 290
Hi,
It's hard to say for sure without seeing a sample and duplicating the problem. But based on the exception, I have a couple of guesses.
1) Is your project using multiple threads? It looks like the rows collection in the grid is getting out of synch, which can happen with threading.
2) It's generally a bad idea to move, delete, or add rows to a collection while you are enumerating that collection (like you are doing here with your 'foreach'. You are not adding or deleting anything, but fixing the row is equivalent to moving it to a new location in the collection.
So what I would do is change the your 'foreach' statement to use an Array of the rows and see if that helps.This works because while you might be changing the order of the rows in the Rows collection, the array will not be affected.
Of course, that doesn't explain why it worked in the old version, but maybe something changed internally in the grid regarding when it updates the order of the Rows.
Todd N said:I was wondering - we do not define Infragistics.Win.UltraWinGrid.UltraGridOverride.FixedRowStyle within our code - does it need to be?
No. Top is the default. You only need to set this if you want the rows fixed at the bottom.
Hi Mike,
This is not a multi-threaded application so #1 does not apply.
The grid is sourced from a DataTable. The grid is also read-only - no row editing is permitted on this grid since the concept is to present 'found' matches from stored proc search result, based on form data. The only editable row is the first row (0?) which is a search row. So # 2 does not apply.
Could it be because the first row is a search row - that your code is failing to correctly calculate the index? (since the exception states index is out of range?). I have not been able to reproduce this failure - it just shows in our error log as occuring occassionaly with same exception error.
A forum search noted others getting exceptions on Fixed = true also, figured I'd add another. I have cleaned up some some of this form - added a for loop using this:
for (int i = 0; i < this.ResultsUltraGrid.Rows.Count; i++) {this.ResultsUltraGrid.Rows[i]. ... to index each row in the table
I would include a code sample - but this app is very large - over 200 forms, so I'd have to create a new one - I will if this happens again, but like I said - it happens at random, have not been able to reproduce this manually.
Doesn't make much sense - rows are already in the table - your suggestion may have merrit though I think there is a deeper flaw. Indexing the for-loop on row[index] - and moving a row from say row[3] to row[1] - this would throw all rows out of sequence and the next check on row[i].value could have already been checked - thereby causing resequenced rows to possibly not even get analyzed.
So the question arises - how do you set more than one row to Fixed = true at the same time??? There should be a 'SetMultipleFixed(DataRow row1, ...)' function that would mark rows to be set as fixed, then - regenerate the table order. I don't have time to download source and investigate this - so if you can, please answer this question, or tell me that they do get marked and resequenced or something.
Hi Todd,
Todd N said:The grid is sourced from a DataTable. The grid is also read-only - no row editing is permitted on this grid since the concept is to present 'found' matches from stored proc search result, based on form data. The only editable row is the first row (0?) which is a search row. So # 2 does not apply.
Umm... why doesn't #2 apply?
If using a BeginInvoke did not help, then I'm afraid I am out of ideas. Can you post a small sample project which demonstrates the exception so we can check it out?
Actually... another possibility just occurred to me.
I assume that the Exception never occurs the first time you set Fixed to true on the row, it probably only occurs on the second or subsequent row. Is that correct?
If so, then perhaps the issue is that the grid hasn't yet updated the index of that row when you are fixing the next row.
If that's true, then you might be able to get around it by forcing the grid to update the indices after each row is fixed. So keep the BeginInvoke and immediately after you set the the Fixed property to true, try calling:
grid.Update();
That will force the grid to paint, which should verify all the row indices.
Found it... caused when reassigning a new datasource does not reinitialize the grids internal FixedRow table.
The problem is that despite a new datasource being assigned to the grid - it retains its prior FixedRow table, causing the index to exceed the row count of the data.
With our situation, onload it sets one row to the FixedRow table, then the a form selecton causes a reload and assigns a new datasource and tries to set all 4 rows of the new datasource as Fixed, resulting in trying to add a 5th row to the Fixed table and throws the exception.
I would suggest you bug this and add an DataSource changed event to delete prior content from the grid.FixedRow table.
I tried this out and I cannot reproduce the exception. I have attached my sample project here so you can see if I am doing something differently than you are.
Basically, I bind the grid to a table with a single row and fix that row.
Then I bind the grid to a new DataTable with 4 rows and fix all four of them.
It works just fine for me.
I do have the same issue with 2011 volume 2... The same code was working fine in the previous version (2009 vol 2) but now I had to include a new line of code before updating the Datasource (datatable) to avoid this issue...
if (_grid.ActiveCell != null) _grid.ActiveCell.Activated = false;