Undo not propagated to child objects if _bindingEdit true? (CSLA 3.0.4)

Undo not propagated to child objects if _bindingEdit true? (CSLA 3.0.4)

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


rsbaker0 posted on Wednesday, October 08, 2008

This is a ERLB with parallel editing form use case. I've found that when I call UndoChanges() on a root object, the child objects don't get undone.

Here is the code that is skipping the undo in UndoChanges(). As a result, I have a "partially undone" object at this point and changes to the child (a BLB in this case) cannot be undone.

Since the grid is managing the editing, I'm not doing my own BeginEdit/ApplyEdit in this case. So, the result is that Undo seems to be working fine for fields but not child lists.

if (!_bindingEdit)

((Core.IUndoableObject)value).UndoChanges(this.EditLevel);

 

RockfordLhotka replied on Wednesday, October 08, 2008

You know, I can hardly wait until Windows Forms is entirely replaced by WPF. The idiosyncracies involved in WinForms data binding are ridiculous.

I don't know the answer to your issue right off, and won't have time to research it in the near future.

It is true that somewhere in the past few versions (3.0 I think) CSLA changed to match the DataTable in terms of how it does or doesn't cascade undo operations from data binding. This was necessary because Windows Forms specifically expects DataTable behaviors - which means no cascading. This may have caused your issue, but it solved a TON of common issues faced (knowingly or unknowingly) by everyone using WinForms.

Whether it is possible, or even desirable, to special-case ERLB is questionable and would take serious research.

I'll be honest, ERLB was never designed to support a row that contains an object graph. It was designed to support a row that contains a single object. So it doesn't entirely surprise me that there are issues cropping up when each row is an entire object graph, because that's outside of the design parameters I considered.

All I can offer at this point is to put this thread into the wish list and perhaps look into it in a few months when I get a chance.

rsbaker0 replied on Thursday, October 09, 2008

Can you point me to a use case in ProjectTracker that actually utilizes "not" cascading so I can study it? I'm just trying to understand why this makes sense.

(Incidentally, if the child object didn't actually exist in the previous state, then the current implementation WILL "cascade" the undo to the child by removing it :)

Meanwhile, I'll either have to add a "CascadeUndo" switch or forgo IEditableObject entirely...

 

RockfordLhotka replied on Thursday, October 09, 2008

ProjectTracker doesn’t actually use ERLB.

 

ERLB is designed for one very narrow and specific scenario: retrieving a list of objects that are edited in-place within a DataGrid or similar control, where changes made to that row are committed when the user moves off that row.

 

Anything outside that narrow and specific scenario is out of the scope for the ERLB design. So if something outside that scope works then we can celebrate, and if it doesn’t work that’s to be expected.

 

Rocky

 

RockfordLhotka replied on Thursday, October 09, 2008

Btw, I don’t mean to come across as harsh on this thread. I’m doling out bits of time between revising chapters and traveling 5 out of 6 weeks and pretending I have a family (ha!), so I really have little time to help or focus on stuff that’s not in the 2008 book or part of my conference sessions. Windows Forms is not part of any of that (except briefly in Chapter 10) and is really way outside my sphere of focus right now.

 

So I mean to be firm, not offensive or harsh. ERLB really is designed for that very narrow and specific scenario. You are outside that scenario. It doesn’t surprise me that you are having issues. They may not be solvable within the context of ERLB.

 

You may need to create your own base class – and I’m not entirely sure that would even be possible given the constraints of WinForms data binding. Those constraints are what they are, and they aren’t designed with the flexibility of objects in mind – they are design with the DataTable in mind.

 

You may need to consider disabling IEditableObject. Basically abandon the confines of data binding and handle UI events yourself to force the object graph to behave as desired. I suspect this may be the only realistic solution to your problem.

 

A given object can not be bound to more than one bindingsource. The bindingsource/data binding infrastructure just doesn’t support that (not a CSLA thing – a data binding thing). But what you are doing almost certainly involves an object being bound to more than one bindingsource (or equivalent) – which is why I say that you may have to entirely abandon data binding to meet your scenario’s requirements.

 

Rocky

rsbaker0 replied on Thursday, October 09, 2008

^^^

No offense taken, and you got me moving in a better direction.  I know you are busy so I appreciate your responding to my questions.

I'm experimenting with turning off IEditableObject and it's working very well so far. I've had to implement an "object broker" for lack of a better term that keeps track of the current object being edited in various grids and emulates ERLB behavior by saving the object being tracked anytime the corresponding BindingSource.CurrentChanged event is fired.

If anyone else has any input into potential pitfalls into doing your own BeginEdit/ApplyEdit/CancelEdit processing versus letting the bindings do it automatically via IEditableObject, I'd certainly be interes

 

 

Copyright (c) Marimer LLC