Detecting when CancelEdit() is being called.

Detecting when CancelEdit() is being called.

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


rxelizondo posted on Monday, November 12, 2012

 

Hello,

I have a couple of objects where I override the OnPropertyChanged and OnChildChanged functions. 

All is good until I call the “CancelEdit()” fuction because “CancelEdit()” will eventually trigger a call to the OnPropertyChanged and OnChildChanged functions and I have code on the OnPropertyChanged and OnChildChanged function that I don’t want to execute when a  “CancelEdit()” is taking place.

So ideally, I would want to be able to detect when the OnPropertyChanged and OnChildChanged functions are being called due to a call to the “CancelEdit()” method.

My first thought was to override “CancelEdit()” to set up a flag that indicated the method was being called but it looks like “CancelEdit()” is not virtual.

I understand that there may be better ways to solve the problem I am experiencing but this is my first stab at trying to fix it.

Any help is appreciated.

Thanks.

 

JonnyBee replied on Monday, November 12, 2012

Look at the code in UndoableBase.cs:

    /// <summary>
    /// This method is invoked after the UndoChanges
    /// operation is complete.
    /// </summary>
    [EditorBrowsable(EditorBrowsableState.Advanced)]
    protected virtual void UndoChangesComplete()
    {
    }

    /// <summary>
    /// This method is invoked before the UndoChanges
    /// operation begins.
    /// </summary>
    [EditorBrowsable(EditorBrowsableState.Advanced)]
    protected virtual void UndoingChanges()
    {
    }

    /// <summary>
    /// Restores the object's state to the most recently
    /// copied values from the state stack.
    /// </summary>
    /// <remarks>
    /// Restores the state of the object to its
    /// previous value by taking the data out of
    /// the stack and restoring it into the fields
    /// of the object.
    /// </remarks>
    [EditorBrowsable(EditorBrowsableState.Never)]
    protected internal void UndoChanges(int parentEditLevel)
    {
      UndoingChanges();

      /// Undo code goes here

      UndoChangesComplete();
    }

rxelizondo replied on Thursday, November 15, 2012

 

Jonny,

Sorry for my late response, I got caught up with some other stuff and was unable to follow up on your response until just some time ago.

I tried your suggestion and it worked great (thank you very much), nevertheless, something does not feel right with what I am doing.

The reason I say this is because is my understanding that the  CSLA preferred method of having a parent object listen to changes on its child objects is through overriding its “OnChildChanged” function. But unless I am the exception to the rule, many times is necessary to skip some of the code residing under the “OnChildChanged” function when a cancel edit is in progress (This may be to avoid side effects or for performance reasons). 

Having said that, I would have expected that the CSLA would have included some sort of built in flag indicating if a cancel edit is in progress so that people could use that flag inside their “OnChildChanged” functions to make determinations on whether to exclude running certain code or not.

Does this make sense? Does it make sense for the CSLA to have such built in flag?

 

JonnyBee replied on Friday, November 16, 2012

Hi,

If you have your own intermediate base classes it's easily extendable.
It's really up to Rocky to make the decision on whether or not to add and make available flags like:

My "fear" is that there will be a LOT of these flags.

It's one thing for the "parent" object - but what if the OnChildChanged is called because the child object is performing  a "CancelEdit".
You are probable aware that DataBinding will also call the methods frequently (at least in Windows Forms) for each edit of a field  (either ApplyEdit/EndEdit).

rxelizondo replied on Friday, November 16, 2012

Thanks Jonny,

The truth is that the reason why we needed to have a way to detect when a cancel edit was in progress was due to some special circumstances, and after looking further into the matter we are pretty sure there are probably better ways to handle our scenario so that we don't have to rely on such flag.

As of now, you solution helps us move on and give us some extra time to think things through a little better.

Thanks a lot!

Copyright (c) Marimer LLC