CSLA .NET

Hi all

I thought and hoped EditLevel issues were behind me but unfortunately not quite :( .  I've been bashing my head with this and not getting far. I'm running CSLA 3.0.3 and following the ProjectTracker example for binding, rebinding, cancel etc. It all works well when I only have two levels, i.e, a root and child collection. Things don't go well with grandchildren. The problem is mostly if I delete a child and then Cancel.

I guess my basic question is:  Is there a systematic way of extending the binding stuff in ProjectTracker to three or more levels / generations?  The relationship between child and grandchild bindingsource mirrors what we do with root and child. i.e, the grandchild bindingsource's DataSource is set to the child bindingsource and its DataMember is set to the collection property of the child object. I'm a little unsure how to unbind the child bindingsource using the UnbindBindingSource() code. Is it considered a root as far as the grandchild collection is concerned?

I've done some tests monitoring EditLevel. To make this as simple as possible, there is only one child and its grandchild collection is empty. I've seen the same thing happening with grandchildren.

I'm reporting four EditLevel numbers in this order: root, child collection, child and grandchild collection.

Before the first BindUI()
0,0,0,0

After BindUI
2,1,2,1  (ProjectTracker does the same for the first three).

Now if I delete the child and then press cancel then before BindUI (i.e, after CancelEdit() on the root) I get 0,0,0,1. The root BeginEdit() in BindUI then fails with an Edit Level mismatch.

I think I need to get the grandchild collection down to zero (before the delete?) but I'm struggling to figure out how to do that.

I hate to say it but this was working on CSLA 3.0.0 with code similar to ProjectTracker 3.0.0

Thanks for any help
Ross

I quickly updated my test project

(http://www.lhotka.net/cslacvs/viewvc.cgi/samples/trunk/RootChildGrandchildWinFormTest/)

to use the 3.0.3+ binding technique and I don't see a failure case there. Maybe I'm not doing something right as a user to make it fail. Can you use that as a test to replicate the issue?

---

Rocky

Thanks Rocky. I haven't used the SVN before but I'll give it a go.

RockfordLhotka:

I quickly updated my test project

Rocky, I tried the test project and hit the problem immediately. I don't know if somehow my setup is different to yours but all have to do is run the project, delete a child and hit cancel. That gives me an edit level mismatch.

I couldn't edit the root name because of the null strings so I then modified the objects so that they have a non-zero incrementing id and non null name.

I can edit or delete a grandchild and bring it back with Cancel, no problem. Editing or deleting a child and then cancelling is a problem.

Ross

Ross,

We had a similar problem:

• one form showing a root object (some TextBoxes), a child collection (DataGridView) and a grandchild collection(DataGridView)
• root object bound to bindingsource1
• child grid bound to bindingsource2 (DataSource = bindingsource1, DataMember = Children)
• grandchild grid bound to bindingsource3 (DataSource = bindingsource2, DataMember = Grandchilds)

We found that if the Current item of bindingsource 2 changed, EndEdit() was not being called automatically on the Current (grandchild) item, leaving it at EditLevel 1. We solved this problem by calling EndEdit() ourselves. I don't know what event we hooked, but I can look that up if you're interested.

Hope this helps!

Cheers,
Herman

 

McManus:

We found that if the Current item of bindingsource 2 changed, EndEdit() was not being called automatically on the Current (grandchild) item, leaving it at EditLevel 1. We solved this problem by calling EndEdit() ourselves. I don't know what event we hooked, but I can look that up if you're interested.

Thanks Herman. That sounds like the same problem I have. I think you probably used the CurrentChanged event but if you can confirm that some time I'd appreciate it. I've fiddled with similar "fixes" but I haven't had much luck with it. I guess it needs to do either an EndEdit or CancelEdit on the grandchild bindingSource depending on what you're actually doing. I've been concentrating on cancel simply because that's where I first noticed the problem.

Cheers
Ross

Thanks! That does appear to be the solution.

What a PITA this all turns out to be...

---

Rocky

If this is working you then you're having better luck than I am .

I'm trying it on your test app Rocky by putting grandchildrenBindingSource.EndEdit() in childrenBindingSource_CurrentChanged. I think that's what Herman was suggesting. That seems to have made it work for saving after modifying a child but I've had no luck at all making cancel work after deleting a child. I tried CancelEdit instead of EndEdit without success. Unfortunately I'm at the limits of my understanding of how these bindingsources really work or at least are supposed to work.

Ross

Ross, Rocky,

Apparently, calling grandchildrenBindingSource.EndEdit() in childrenBindingSource_CurrentChanged solved just a part of the problem. This call takes care of the fact that the EditLevel of the "Current" GrandChild item changes from 2 to 1 (which is a good thing!).

But there seems to be another problem: suppose we delete Child2. Just before the object is deleted, the value of BindingEdit is True. After deleting the object, the value of BindingEdit is still True.

Now, when we cancel the deletion, we first Unbind the bindingsources. This results in all objects being at EditLevel 1 (which is a good thing too!). Then CancelEdit() is called on the Root object. As a result, Child2 is added to the ChildList again. Both have an EditLevel of 0.

BUT: The GrandChildList of Child2 (and all its items) have an EditLevel of 1!!! The reason for this is that UndoChanges() wasn't called on the GrandChildList of Child2 ==> the result of BindingEdit having the value True.

When the root object is rebound again, EditLevelMismatchException is thrown.

 

The same problem occurs in the following sitation:

1. Delete Child2
2. Apply changes
3. Change Name of the Root object
4. Cancel the change

Note that the deletion of Child2 was confirmed, but canceling a new edit puts the deleted items back in the list again!!

Complex stuff, isn't it?!?!

Cheers,
Herman

Thanks Herman. That sounds familiar from my limited testing. I sat down to have another play with it at home last night and noticed that Rocky's test application in the svn has changed from the day before and has some more debugging in it so I think he's looking at it. Good luck Rocky I'm sure it's time consuming at a awkward time and an absolute PITA to debug.

I only have this on one form and the n in n-level undo is never really > 1 for me so for now I've made the cancel button throw away the objects and reload from the db. That has solved my immediate problem.

Cheers
Ross

---

Rocky

Yes, working perfectly.   That's good news. I was worried that we might have to change the binding code in the UI forms again.

My real application uses a Janus grid with the children and grandchildren in a hierarchy so there's no grandchild bindingsource and that's working fine as is a more traditional test application I have.

Thanks
Ross

RockfordLhotka:

Can you test this in your scenarios and see if it does address the issue?

Rocky,

The fix in BusinessBase.DeleteChild, together with the EndEdit() call on the GrandChild object solve the problem.

Forget my remark about confirmed deletions showing up again. It doesn't happen now!

Cheers,
Herman

---

Rocky

Hi,
Some more strange behaviour.

What if you have a collection in the root object but you don't bind it to any bindingsource. The edit level of the first child is 2 and after applying the changes the level 1(which is wrong) and it breaks next time I begin edit.

To fix it I just bound the collection to a hidden grid and let the binding framework do the work.

Is this a problem in the UndoableBase class? I'm using 3.0.4.

Thanks,
Cosmin