Another Undo discussion

xal posted on Wednesday, June 21, 2006

Hi Rocky,
I'm still thinking that csla should provide a way to better to disable undo.
In 1.x if you didn't want to use undo, you just didn't call BeginEdit, and everyone was happy.
In 2.x, the bindingsource object calls BeginEdit automatically, thus forcing you into undo.
I have some objects that may or may not be very heavy (10 child items or 20000). This is not the typical "bad use case situation", because that's the way these objects are supposed to work. It depends on the amount of data loaded by the client.

Now, typically, the object is loaded very very fast. It's setting the BindingManager's datasource property that slows things terribly.

I have set up a NotUndoable() attribute in the field that holds the collection, and efectively, when the binding source attached to my root object calls begin edit, the collection is not stored in the undo stack.

But when I have another binding source that has the first binding source as datasource and that will hold the collection to bind to a grid, this binding source calls begin edit on the collection, and now undo is called on the collection and each of it's items. (This is my assumption of what is happening, the begin edit call is being made, but I'm not certain it's being called by the binding source or the grid).

So again, we need something that allows us to disable undo on an instance base or on a class base.
A NotUndoable() class level attribute would be an option, a protected property for setting Me.Undoable=False would be another.

Anyway, this is just my opinion, but the way things are right now, I'm being forced to alter the framework to disable undo. I hope some of these solutions (or some other solution) is implemented so I won't have to do this anymore...

Andrés

xal replied on Wednesday, June 21, 2006

Hm... I was very wrong... A little more work lead me to find that my problem is an event handler...
Since my object is target of an event raised by itself, the handler is taken as part of the undo operation, serializing it's target (the same object).
I always thought that events didn't live through serialization, but this doesn't seem to be accurate... Can anyone illuminate me here?

Andrés

xal replied on Wednesday, June 21, 2006

It suddenly hit me that I had read about this in Rocky's blog:
Here's the link

But anyway:

1) Should we be storing events in undo?
2) Still, I think there should be a way for us to get rid of undo altogether. Whether it is an attribute, a property or a static parameter. Personally I'd go with the attribute. Otherwise the grids _are_ going to call begin edit in our child objects and undo _is_ going to be used. Whether we like it or not.
The impact should of course be much, much smaller, maybe even unnoticeable, I know. But still, the problem persists. Specially if you have blobs or images that you don't want to seralize...
You can add NotUndoable to every field, but that is a pain.
Would it be much trouble to have a class level attribute Rocky?

Andrés