We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. (Last updated on : Nov 16th 2018).
Unfortunately, activation email could not send to your email. Please try again.
Syncfusion Feedback

Argument out of range during cell edit

Thread ID:

Created:

Updated:

Platform:

Replies:

53066 Dec 7,2006 04:17 PM UTC Dec 11,2006 01:47 PM UTC WinForms 7
loading
Tags: GridControl
Andy
Asked On December 7, 2006 04:17 PM UTC

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

Administrator [Syncfusion]
Replied On 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.

Administrator [Syncfusion]
Replied On 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

Andy
Replied On 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

Andy
Replied On 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

Andy
Replied On 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

Administrator [Syncfusion]
Replied On 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

Administrator [Syncfusion]
Replied On 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

CONFIRMATION

This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

Warning Icon You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.Close Icon

;