I’ve been having a hard time getting the insertion row to behave in exactly the way I need it to. So I tried to implement my own insertion row concept. Unfortunately, the code is not behaving in any way that I would have expected it to in my event handlers.
Is there some kind of time-limit involved when editing cells? Am I restricted from editing the contents of a cell if another cell is already in edit mode? What are the rules for changing cell values in code?
For example, if I try to do this:
Public Sub AddInsertionRow() Dim column As Column Dim row As Xceed.Grid.ValueRow row = New Xceed.Grid.ValueRow FooterRows.Clear() FooterRows.Add(row) Dim cell As Cell For Each cell In row.Cells AddHandler cell.ValueChanged, AddressOf insertionRow_CellValueChanged Next End Sub
Private Sub insertionRow_CellValueChanged(ByVal sender As Object, ByVal e As EventArgs) Dim newRow As Xceed.Grid.DataRow newRow = AddNewDataRow()
Dim editedCell As Cell editedCell = sender
newRow.EndEdit() CurrentRow = newRow —> newRow.Cells(editedCell.ParentColumn.Index).Value = editedCell.Value End Sub
When the debugger gets to the line marked with the arrow, code execution stops as if an exception were raised, but no exception is ever raised. How can I tell when a cell is editable, and when it will exhibit this strange “phantom exception” behavior?
Imported from legacy forums. Posted by Christopher (had 2187 views)
I think this may have been a casting exception that the grid hid from me. It seems that the grid places very restrictive rules on which data types can be converted without specific casting. Where VB would allow a integer value to be copied into a double variable, it seems the grid doesn’t like that. I have since gotten my insertion rows to work.
Imported from legacy forums. Posted by Christopher (had 3119 views)