Hi.
I have GridControl in which I'm trying to edit the values in cells. Whenever I change a value and try to leave the cell, I get an ArgumentOutOfRangeException.
The exception is occuring in SFTable.cs at line 389 (version 3.0.1.0). The code at that line is:
if (colIndex >= colCount || colIndex < 0)
throw new ArgumentOutOfRangeException
"colIndex");
That code is inside an indexer for the SFTable class. The indexer expects a rowIndex and colIndex and is being passed what appear to be legitimate values for the grid control in question (for instance, 6 and 12). The colCount and rowCounts appear to be 2 and 2, however, thus resulting in the out-of-range exception.
This is all buried deep inside the grid-control's internal logic, so I'm pretty much lost as to what's going wrong here.
Any thoughts?
Thanks,
Andy
AD
Administrator
Syncfusion Team
December 8, 2006 06:38 AM UTC
Hi Andy,
This error happens in the SFTable.Item setter method where it checks if SFTable.RowCount ( Model.Data.RowCount) is large enough to save the item.
I guess that in your case you do handle QueryRowCount to return a row count and you do never set Model.RowCount or Model.Data.RowCount
So, to resolve your problem you either need to explicitly set Model.Data.RowCount or if you think that call to the setter should not happen at all find out why the setter was called (Example: if you do handle SaveCellInfo, do you set e.Handled = true)?
In a virtual gridcontrol, the grid.Data object does not allocate any space to hold values unless you explicitly set grid.RowCount and grid.ColCount. Are you setting these values?
Also, in a virtual grid, you should be saving values in SaveCellInfo, setting e.handled = true to indicate the values get saved. Is this being done?
Either of these situations can give a index out of range error.
If you never want the grid to save anything, you probably should always set e.Handled = true in SaveCellInfo. This may be why you are seeing this exception.
Best Regards,
Jeba.
AD
Administrator
Syncfusion Team
December 8, 2006 04:18 PM UTC
Jeba,
Handling the SaveCellInfo event and setting "Handled" to true does the trick. Thanks.
Although I appreciate the flexibility of the control in supporting the storage of cell information even when used as a virtual grid, I would think one of two things could make the control a bit more... programmer friendly:
1) When a grid control is virtual, simply disallow storage of cell contents. That seems more symmetrical to me (virtual grid implies no grid-owned backing-store) and would've been the behavior I expected. In other words, I wouldn't have expected a virtual grid to attempt to do anything at all with a typed in value other than display it until the next refresh. This strikes me as a better "default" behavior".
2) Alternatively, leave support for grid-owned cell information storage in place, but intercept the logic that attempts to store the data and throw a custom exception that basically tells the programmer, your virtual grid is attempting to store your edit changes but you have not taken the required steps to allocate storage for edited values. That would, at least, be more informative then letting it get to the point of an indexing error.
Just my two cents.
Anyway, thanks again for the prompt help.
Andy
AN
Andy
December 8, 2006 04:19 PM UTC
Jeba,
Handling the SaveCellInfo event and setting "Handled" to true does the trick. Thanks.
Although I appreciate the flexibility of the control in supporting the storage of cell information even when used as a virtual grid, I would think one of two things could make the control a bit more... programmer friendly:
1) When a grid control is virtual, simply disallow storage of cell contents. That seems more symmetrical to me (virtual grid implies no grid-owned backing-store) and would've been the behavior I expected. In other words, I wouldn't have expected a virtual grid to attempt to do anything at all with a typed in value other than display it until the next refresh. This strikes me as a better "default" behavior".
2) Alternatively, leave support for grid-owned cell information storage in place, but intercept the logic that attempts to store the data and throw a custom exception that basically tells the programmer, your virtual grid is attempting to store your edit changes but you have not taken the required steps to allocate storage for edited values. That would, at least, be more informative then letting it get to the point of an indexing error.
Just my two cents.
Anyway, thanks again for the prompt help.
Andy
AN
Andy
December 8, 2006 04:20 PM UTC
Jeba,
Handling the SaveCellInfo event and setting "Handled" to true does the trick. Thanks.
Although I appreciate the flexibility of the control in supporting the storage of cell information even when used as a virtual grid, I would think one of two things could make the control a bit more... programmer friendly:
1) When a grid control is virtual, simply disallow storage of cell contents. That seems more symmetrical to me (virtual grid implies no grid-owned backing-store) and would've been the behavior I expected. In other words, I wouldn't have expected a virtual grid to attempt to do anything at all with a typed in value other than display it until the next refresh. This strikes me as a better "default" behavior".
2) Alternatively, leave support for grid-owned cell information storage in place, but intercept the logic that attempts to store the data and throw a custom exception that basically tells the programmer, your virtual grid is attempting to store your edit changes but you have not taken the required steps to allocate storage for edited values. That would, at least, be more informative then letting it get to the point of an indexing error.
Just my two cents.
Anyway, thanks again for the prompt help.
Andy
AN
Andy
December 8, 2006 04:20 PM UTC
Jeba,
Handling the SaveCellInfo event and setting "Handled" to true does the trick. Thanks.
Although I appreciate the flexibility of the control in supporting the storage of cell information even when used as a virtual grid, I would think one of two things could make the control a bit more... programmer friendly:
1) When a grid control is virtual, simply disallow storage of cell contents. That seems more symmetrical to me (virtual grid implies no grid-owned backing-store) and would've been the behavior I expected. In other words, I wouldn't have expected a virtual grid to attempt to do anything at all with a typed in value other than display it until the next refresh. This strikes me as a better "default" behavior.
2) Alternatively, leave support for grid-owned cell information storage in place, but intercept the logic that attempts to store the data and throw a custom exception that basically tells the programmer, your virtual grid is attempting to store your edit changes but you have not taken the required steps to allocate storage for edited values. That would, at least, be more informative then letting it get to the point of an indexing error.
Just my two cents.
Anyway, thanks again for the prompt help.
Andy
AD
Administrator
Syncfusion Team
December 8, 2006 04:20 PM UTC
Jeba,
Handling the SaveCellInfo event and setting "Handled" to true does the trick. Thanks.
Although I appreciate the flexibility of the control in supporting the storage of cell information even when used as a virtual grid, I would think one of two things could make the control a bit more... programmer friendly:
1) When a grid control is virtual, simply disallow storage of cell contents. That seems more symmetrical to me (virtual grid implies no grid-owned backing-store) and would've been the behavior I expected. In other words, I wouldn't have expected a virtual grid to attempt to do anything at all with a typed in value other than display it until the next refresh. This strikes me as a better "default" behavior.
2) Alternatively, leave support for grid-owned cell information storage in place, but intercept the logic that attempts to store the data and throw a custom exception that basically tells the programmer, your virtual grid is attempting to store your edit changes but you have not taken the required steps to allocate storage for edited values. That would, at least, be more informative then letting it get to the point of an indexing error.
Just my two cents.
Anyway, thanks again for the prompt help.
Andy
AD
Administrator
Syncfusion Team
December 11, 2006 01:47 PM UTC
Hi Andy,
Thanks for your patience.
Regarding the Issue 1:
I am really sorry to inform you that I am not clear about your question.Can you please give me a more details regarding this issue?
Regarding the Issue 2:
There is no buit-in support for this. To need this, you would have to derive the GridControl and override the OnSaveCellInfo method to display the warning text for editing values in a grid. Here is a code snippet
public class MyGrid: GridControl
{
public MyGrid():base()
{}
protected override void OnSaveCellInfo(GridSaveCellInfoEventArgs e)
{
if( e.Handled && this.Data.RowCount == 0 )
MessageBox.Show("You need to handle the SaveCellInfo for storing the edited value");
base.OnSaveCellInfo (e);
}
}
Best Regards,
Haneef