ERLB Remove method doesn't remove

ERLB Remove method doesn't remove

Old forum URL: forums.lhotka.net/forums/t/8733.aspx


CalvaryLogic posted on Friday, March 26, 2010

I'm having quite a bit of trouble figuring out why Remove will not remove an item from a ERLB instance.  The Add method works fine.  I did create workaround that works.  I added a Delete method to my list which removes from the Items list of the ERLB, like this...

Public Sub Delete(ByVal object As MyClass)

 

 

     Me.Items.Remove(object)

 

 

     Me.OnRemoveEventHooks(object)

 

 

End Sub

However, I'm curious as to why the Remove method isn't working.  I also tried RemoveAt, and it also does not remove an item from the list.  I have this bound to a ListBox, but I did try removing from the list without it being bound to the ListBox (thought maybe the ListBox was doing something to cause the issue).  Remove is returning a "True", but that's not saying anything conclusive judging by what is found in System.Collections.ObjectModel.Collection<T> using .NET Reflector...

public bool Remove(T item)
{
    if (this.items.IsReadOnly)
    {
        ThrowHelper.ThrowNotSupportedException(ExceptionResource.NotSupported_ReadOnlyCollection);
    }
    int index = this.items.IndexOf(item);
    if (index < 0)
    {
        return false;
    }
    this.RemoveItem(index);
    return true;
}

As you can see as long as it finds the object in the collection, and RemoveItem doesn't throw an exception, it will return a True... regardless of whether or not RemoveItem actually performs its job successfully.  Seems like Microsoft has a flaw in logic there.  I also tried using ERLB's override of RemoveItem within my Delete function, instead of Items.Remove and that's not working either.  So, it looks like all roads lead to ERLB.RemoveItem.  My list's properties are AllowEdit = True, AllowNew = False, AllowRemove = True, so that seems to be in order.  Next stop CSLA source code to see what's going on in there, but if anyone has a quick answer I'd appreciate it.

Thanks,
Matt

rsbaker0 replied on Friday, March 26, 2010

The first thing I would look at is does it actually find the item in the collection?

CSLA went to reference equality back in 3.0 or so versus value equality, and it is very easy for you to end up holding onto a stale object reference with the way CSLA implements saving. (Any time you save an object in CSLA, it is almost always the case that existing references you have to the object are old and now must be updated with the returned value e.g. obj = obj.Save()).

 

 

 

CalvaryLogic replied on Friday, March 26, 2010

rsbaker0

The first thing I would look at is does it actually find the item in the collection?

CSLA went to reference equality back in 3.0 or so versus value equality, and it is very easy for you to end up holding onto a stale object reference with the way CSLA implements saving. (Any time you save an object in CSLA, it is almost always the case that existing references you have to the object are old and now must be updated with the returned value e.g. obj = obj.Save()).

 Thanks for your reply!  And those are very good points, which I checked and everything looked good.  It does find the item in the collection.  Based on the code that I saw in Reflector the only way it could return True is if the item is in the collection.  Just to be safe though (not fully trusting Reflector) I did my own IndexOf and it did find it in the list.  And also did GetHashCode calls at key points to make sure it was the same object and it was.  I'm not doing any type of save with the list at that point in the code, so no chance for it to be re-loaded as a new object. 

Thanks,

Matt

rsbaker0 replied on Friday, March 26, 2010

Yes, if you tested the return from Remove() and it was true, I'd this this would be a good indicator. 

What happens if you test the .Count property value before and after the Remove(). Does it go down by 1? (If so, this raises the question of what you are looking at that doesn't reflect the removal).

(Also, it certainly would be worth having the CSLA project in your solution for debugging rather than just referencing the .DLL's if that is feasible. I find this almost indispensable for troubleshooting weird CSLA issues)

RockfordLhotka replied on Saturday, March 27, 2010

If this is an ERLB, have you checked to make sure the delete operation succeeds? ERLB will immediately trigger the delete operation, and if that fails the item won't be removed from the collection, because of course it wasn't removed from the database.

CalvaryLogic replied on Monday, March 29, 2010

RockfordLhotka

If this is an ERLB, have you checked to make sure the delete operation succeeds? ERLB will immediately trigger the delete operation, and if that fails the item won't be removed from the collection, because of course it wasn't removed from the database.

Ah yes, of course.  I don't have any server-side code handling the delete from the database.  The situation is that this is a new list that is being constructed on the client, and will be inserted to the database upon clicking a Save button.  I've seen several of your posts where you state the specific purpose for ERLB is for databound grids that save immediately after an edit, but it didn't click with me that it would wait for a successful delete from the data store.  Makes complete sense for those purposes.  Maybe a BLB would be more appropriate for what I'm doing.

Thanks Rocky!

Matt

CalvaryLogic replied on Monday, March 29, 2010

rsbaker0

Yes, if you tested the return from Remove() and it was true, I'd this this would be a good indicator. 

What happens if you test the .Count property value before and after the Remove(). Does it go down by 1? (If so, this raises the question of what you are looking at that doesn't reflect the removal).

(Also, it certainly would be worth having the CSLA project in your solution for debugging rather than just referencing the .DLL's if that is feasible. I find this almost indispensable for troubleshooting weird CSLA issues)

The count doesn't go down after the Remove.  Good point on the CSLA source code.  I think I'll do that.  Rocky nailed it, see below....

Copyright (c) Marimer LLC