CSLA .NET

Rocky,

There seems to be a bug with regards to edit level if you are using Managed fields (PropertyInfo) for your field declarations.

I have a project that has multiple objects with Children and some with Grandchildren. I kept getting Edit Level Mismatch in wierd places so I downloaded your rootChildGrandChild test app and my objects did not look like yours with regards to Edit Levels.

So I converted my app to use CSLA 2 style fields like the test app and everything worked fine. Then I converted your test app to managed fields and it yielded erroneous results like my app did previously.

From my small amount of slueth work it appears that UndoableBase propagates the call to the child collections on line 145

// this is a child object, cascade the call
                  if (!_bindingEdit || value is FieldManager.FieldDataManager)
                    ((Core.IUndoableObject)value).CopyState(this.EditLevel + 1);

This only happens when using managed fields as the old style field declaration does not match the criteria.

But shouldnt the field manager be smart enough to propogate the child calls or not?

I hope I am clear enough, I can provide more detail if needed.

Ryan

Thanks for researching this issue.

I am not sure what you are suggesting for a solution though?

UndoableBase cascades the call to FieldManager. In the FieldDataManager object the call is then cascaded to any child objects.

Oh, are you saying that the FM needs to include the _bindingEdit check before cascading the call?

I have changed the 3.5.1 C# code in svn to pass the BindingEdit value to each child so the child can decide whether to act on the method call. This inversion of control makes the code cleaner overall, and appears to solve the problem.

Can you grab the current code from svn and see if it resolves your issue(s)?

Rocky,

I am downloading the SVN version now, will test as soon as I get a chance today.

Ryan

Rocky,

The changes appear to fix the edit level issue for child objects while loading an existing object. However when you modify a child object on the existing parent, or create a new parent you get edit level mismatch exceptions. I am digging into this a bit deeper to see if i can give you some examples on how to replicate the problem.

Ryan

Rocky,

Problem number 1 is easily replicated with your RootChildGrandchildTest. Just try to add a new row in the grid and the app will get stuck in an endless loop on lines 379 and 380 in Core.UndoableBase.cs . I am not sure what is causing this, except for the obvious, bindingEdit = true so it never goes in to update the edit level.

Rocky,

I made a change in my BusinessListBase class, well its more of a hack really and I know it is not the best way to fix this. But here is what I did:

private bool _firstTime = true;

    void Core.IUndoableObject.CopyState(int parentEditLevel, bool parentBindingEdit)
    {
        if (!parentBindingEdit || _firstTime)
        {

            CopyState(parentEditLevel);
            _firstTime = false;
        }
    }

This is lines 230 - 240 in BusinessListBase. With this change it lets the edit level increase 1 time to prevent the endless loop from occurring. Seems to work fine in the UI on the RootChildGrandchildtest app, and the edit levels appear to match.

Rocky,

This fix seems to be working great! I am able to save and cancel all objects in testing right now.

The one problem I am having though, which I will make a new post for, is that if I am using an infragistics grid and I call CancelEdit() the edit levels to do reset on one of my grandchild objects in the collection. It works fine with 2 windows grids or even with a Janus Grid though.

Ryan