Okay, I have a simple object here with a few properties and a child collection.
I'm having more trouble. For some reason calling CancelEdit() reverts the changes to all of the child objects in the root collection and their properties. However the properties in the nested child collection does not get reverted. It looks like they undo code is actually running on my nested child collection and child objects, but the values don't change. Any ideas here? I've searched through the forum and I did make sure all of my ID values are unique.
When you say "values don't change" is this through data binding, or is your test directly calling the properties?
In other words, I have unit tests in cslatest that do this, but obviously without data binding. If you are using data binding, my guess is that somehow the UI simply isn't refreshing after the values have changed.
In 2.0+ remember that events from child objects IN A COLLECTION
automatically trigger a ListChanged event from the collection. But YOU must handle
that ListChanged event in your root object (the parent of the collection) and call
OnPropertyChanged or OnUnknownPropertyChanged at that point.
Also remember that the IsDirty flags have nothing to do with the
events at all. You override IsDirty in your root (parent of the collection) to
also check the collection’s IsDirty flag – and that in turn checks
the flags of all the children it contains.
Rocky
From: burmajam
[mailto:cslanet@lhotka.net]
Sent: Thursday, April 12, 2007 8:59 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] CancelEdit doesn't undo child collections?
I'm trying to solve similar problem for few hours. change on
child collection or child doesn't trigger OnIsDirtyChanged and if I make in
parent object change and undo it, only parent is undone but it still stays
dirty. What makes me angry is that a year ago I've made something similar and
it worked correctly ">
The undo behaviors DO NOT require or rely on these events at
all. They are automatic (assuming you have the parent-child relationships set
up correctly).
The events are only important if you are using Windows Forms (or
WPF) data binding, or if your custom UI framework uses those events.
Rocky
From: Jimbo
[mailto:cslanet@lhotka.net]
Sent: Saturday, April 14, 2007 9:26 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: CancelEdit doesn't undo child collections?
I can't find any reference in the Book that says YOU MUST
handle this event. The indexed references to calling OnPropertyChanged and
OnUnknownPropertyChanged are equally uninformative in respect of what may be
needed in the BO.. If you must handle it for undo to operate as expected
then one would think that it would be spelled out in some detail. Lets
have some good examples.
Jimbo
I am having problems cascading CancelEdit from the parent object to the child collection (using ver 3.5.1). My 'Cancel' handler is shown below:
' suspend events
ProviderBindingSource.RaiseListChangedEvents =
FalseCMEEntriesBindingSource.RaiseListChangedEvents =
False ' UnbindUnBindBsource(CMEEntriesBindingSource,
True, False)UnBindBsource(ProviderBindingSource,
True, True) ' Rebind data Me.ProviderBindingSource.DataSource = Nothing Me.CMEEntriesBindingSource.DataSource = ProviderBindingSource Me.ProviderBindingSource.DataSource = _provider ' resume eventsProviderBindingSource.RaiseListChangedEvents =
TrueCMEEntriesBindingSource.RaiseListChangedEvents =
True ' Refresh UIProviderBindingSource.ResetBindings(
False)CMEEntriesBindingSource.ResetBindings(
False)Is it possible I am missing something? My BO is of the BB class and the collection is of the BLB class. Thanks in advance.
Dan
Data binding does not work if undo operations cascade from parent to children. So when using data binding, as you show in your code, CSLA only does the undo operation on the "current" object - based on the currency rules of data binding.
If you want undo operations to cascade through the entire object graph, then you must follow the pattern described in the Using CSLA .NET 3.0 ebook and illustrated by the current PTWin code.
Specfically, you can call BeginEdit(), CancelEdit() and ApplyEdit() manually, but only when the objects are not bound to the UI.
Data binding will still do its thing too - using undo on a per-object basis based on data binding's currency rules.
But doing the manual calls allows you to do form-level cancel buttons and other more complex scenarios (modal dialogs, etc).
Frankly the whole thing is way more complex than we could ever hope. Fortunately the WPF and Silverlight binding models are (at least currently) a lot simpler than Windows Forms and that makes things a lot easier.
Many thanks for the feedback. I was using a somewhat modified version of the "unbindUI" routine from the PTWin source (and book); I re-wrote the code and it worked.
Dan.
Hi Rocky,
Tnx for your reply. Subscribing to ListChanged event was missing part, but there are also a lot of needed steps for binding, save and and undo to work correctly. Don't ask me what I've done, even I don't know, but it works now.
Tnx again
Copyright (c) Marimer LLC