Hello,
My team is in the process of upgrading our configuration from AGP 2.9 to AGP 3.1. During our initial testing, we found that our delete behavior is not working by causing an invalid operation on the EditOperation.
We tracked down the issue to the change in behavior for the EventToken property on the EditOperation class.
This is a direct copy of the summary comments for the property:
//
// Summary:
// Provides a way for calling code to identify a particular EditOperation within
// a subsequent EditEvent. Setting an EventToken in an EditOperation is optional
// - by default it is null. If set to a non-null object, the EditOperation is subsequently
// successful, and, an EditEvent is published, then the EventToken object set here,
// will be available from the corresponding ArcGIS.Desktop.Editing.Events.EditCompletedEventArgs.EventToken.
However, there was an apparent bug in AGP 2.9. In 2.9, when creating a chained edit operation, the parent was not being set to the internal private field. As a result, the EditOperation, if it was the parent or the chained instance, held on to its own EventToken instance. Look at the EventToken property here:
public object EventToken
{
get
{
if (_parentOperation == null)
{
return _eventToken;
}
return _parentOperation.EventToken;
}
set
{
ThrowIfReentrant();
_eventToken = value;
}
}
In AGP 2.x, the _parentOperation field was always null. Therefore, when the EventToken was assigned on a ChainedEditOperation instance, it would hold onto its own EventToken and the getter would always return that instance, not the parent's instance.
In AGP 3.x, this changed. You apparently "fixed" this bug. Even though you can assign the EventToken to a ChainedEditOperation, it is only returned IF the parent is null. But the parent is NEVER null for a ChainedEditOperation.
Why do you have the parent null check in the first place? Based on the comments, it seems like you should be able to assign the EventToken independently of the parent, which is what we do in our code. We use the EventToken in some very important use cases. Working around this fix is difficult (not impossible, but difficult).
Would it be possible to revert the fix in some way to bring back the original behavior? Perhaps add an overload for the CreateChainedEditOperation where you can pass in the EventToken you want to use? Though it may not be possible to know at the time the method is called what to provide. Or maybe instead, the overload takes a Boolean to flag to use a local instance instead of the parent EditOperation's instance of the EventToken.
The point I am trying to make is that this was a VERY subtle change in behavior and the only reason I figured it out is because I am very good at debugging my own code. I also compared the call stack between the use of AGP 3.x SDK AGP 2.x SDK (which is no easy feat).
I am hoping someone from ESRI can respond to this with details on what is truly expected with the use of the EventToken. It really makes you wonder what other subtle changes might be in the SDK that could cause unexpected behavioral changes.
Kris Culin
