Error when pressing escape key on a filtered list bound datagridview

Reply

JonnyBee replied on Sun, Jan 13 2013 2:42 AM

rated by 0 users

Which version of CSLA do you use? 

In windows forms it is essential to bind/unbind properly before calling Save. This is the most common reason for EditLevelMismatch Exception.

See my post: http://jonnybekkum.wordpress.com/2009/10/20/forms-databinding-the-magic-sequence-of-binduiunbindui/

Reply

Helius replied on Sun, Jan 13 2013 5:23 AM

rated by 0 users

Hi Jonny, 

I have tried with the latest version of CSLA 4.5,  and the problem persists. I am using CSLAExtender to manage the  bind/unbind of bindingsources. The save is working ok when i filter, edit data in the grid, filter, edit again and save in the end. The problem occurs only when i try to add any new rows in the filtered datagrid. 

Also there is that problem when adding a new row in the empty datagrid, and directly pressing ok. I think may be these two errors are related, and probably i am missing something there.

Reply

Cymro replied on Tue, May 14 2013 6:32 AM

rated by 0 users

I get this too...but I don't think it is an "Edit Level Mismatch" type exception.  I believe that the issue is in the FilteredBindingList (and posibly the SortedBindingList) implementation of ICancelAddNew.CancelNew (which is called by the DataGridView binding).  

For some reason the DataGridView calls CancelNew with an index of -1 when the list is empty. and this causes an issue in the FilteredBindingList.OriginalIndex function.  It attempts to find the OriginalIndex based on an index of -1.

 void ICancelAddNew.CancelNew(int itemIndex)
    {
      ICancelAddNew can = _list as ICancelAddNew;
      if (can != null)
        can.CancelNew(OriginalIndex(itemIndex));
      else
        _list.RemoveAt(OriginalIndex(itemIndex));
    }

  private int OriginalIndex(int filteredIndex)
    {
      if (_filtered)
        return _filterIndex[filteredIndex].BaseIndex;
      else
        return filteredIndex;
    }

 This can be replicated very easily by binding a FilteredBindingList to a DataGridView with DataGridView.AllowUserToAddRows = True.  Apply a filter to the list which will cause the grid to be empty, click in the new row and then press escape.  You should get a System.ArgumentOutOfRangeException.

Reply

Tiago Freitas Leal replied on Tue, May 14 2013 5:18 PM

rated by 0 users

Hi Cymro,

I feel a bit lost after your edit comment. The fix below applies to SortedBindingList.

Right?

The fixed line is missing on FilteredBindingList.

Right?

Cymro:

void ICancelAddNew.CancelNew(int itemIndex)
    {
      //if (itemIndex > -1) return;
      if (itemIndex <= -1) return;

      ICancelAddNew can = _list as ICancelAddNew;
      if (can != null)
        can.CancelNew(OriginalIndex(itemIndex));
      else
        _list.RemoveAt(OriginalIndex(itemIndex));
    }

Reply

Cymro replied on Wed, May 15 2013 2:33 AM

rated by 0 users

Hi Tiago,

Yes in our current version of CSLA - 4.0, the line was completely missing from FilteredBindingList and incorrect in the SortedBindingList.  The implementation of this method should be the same in both classes.

Reply

Cymro replied on Thu, May 16 2013 9:13 AM

rated by 0 users

I have tested this further and it appears that there are other issues around the CancelNew behaviour with a DataGridView.  The reason I was looking at this was because we are attempting to use a SortedBindingList and FilteredBindingList with a DynamicBindingListBase derived class.  The issue here is that when the list is Sorted (or filtered) the cancel new fails and leaves the invalid new item in the list.

I have tracked this down and found the issue but not a satisfactory resolution

When a new row is added to a DataGridView the AddNew adds the object to the end of the list.  Even if the sorted is list is sorted it still goes at the end of the sorted list (which is what we want).

The issue is with the way that the DataGridView's DataBinding handles the cancelling. 

1. The DataGridView calls CancelEdit on the child object through (IEditableObject.CancelEdit). 
2. The changes get rolled back in the child object, but this has the side effect of raising OnUnknownPropertyChanged.
3. PropertyChanged is handled by the parent BindingList and raises the IBindingList.ListChanged event with a ListChangeType of "Reset". 
4. The SortedBindingList handles the ListChanged of the source list and calls DoSort, resorting all the items in the list (including the new item).  This is where the problem lies!!!
5. The DataGridView then calls ICancelAddNew.CancelNew passing the last row index - but this is no longer where our item is, because it has been re-sorted into the middle of the list somewhere.

We do not see the effect of this issue in a BusinessBindingListBase because as part of the CancelEdit on the child, it calls to the parent list to remove it (when the EditLevel < EditLevelAdded) using IParent.RemoveChild(T child).  With a BusinessBindingListBase the implementation of this method removes the child, whereas with a DynamicBindingList does not.  Therefore, with a BusinessBindingListBase the new child is removed from the list before the CancelNew is even called (as part of step 2 above) which masks the issue with the CancelNew implementation of the SortedBindingList.

I am unhappy with this "fix" for two reasons. Firstly, the original comment in the method...

...suggests that this was thought abount and decided this should not be done here.  And secondly because this just masks the real issue of the list getting re-sorted during the whole cancel process.

Now the obvious "fix" is to have the DynamicBindingList remove the child as part of the IParent.RemoveChild implementation as follows...

    /// <summary>
    /// This method is called by a child object when it
    /// wants to be removed from the collection.
    /// </summary>
    /// <param name="child">The child object to remove.</param>
    void Core.IEditableCollection.RemoveChild(Csla.Core.IEditableBusinessObject child)
    {

      Remove((C)child);
    }

I am unhappy with this "fix" for two reasons. Firstly, the original comment in the method...

      // do nothing, removal of a child is handled by
      // the RemoveItem override

...suggests that this was thought abount and decided this should not be done here. And secondly because this just masks the real issue of the list getting re-sorted during the whole cancel process.  Does anyone have any thoughts?