topic Re: Pro 2.2 issues? in ArcGIS Pro SDK Questions

Pro 2.2 issues?

MKa — Mon, 16 Jul 2018 19:15:46 GMT

Has anyone had any issues after their upgrade to Pro 2.2. It seems that most of my difference and merge functions are not performing as they did in 2.1? I am wondering if anyone else is having this issue or I need to do something different when saving the result of that operation?

Re: Pro 2.2 issues?

Wolf — Mon, 16 Jul 2018 20:03:18 GMT

Hi M,

I you can publish a code snippet that you suspect of not working the same I will try the snippet in both versions and let you know if there's an issue.

Thanks,

Wolf

Re: Pro 2.2 issues?

MKa — Sun, 12 Dec 2021 08:41:57 GMT

Sorry I couldn't get back to you yesterday. What i am trying to do is simply get the difference between to of the same feature from our feature service. Two of the same type Polygons cannot occupy the same space. So when you draw one polygon over one or more of the same type polygon(s), it gets the total of those intersecting polygons, and gets the difference of the new polygon minus the intersecting polygons, this is a small part of that code.

I have an object that gets the difference geometry of features of the same type, it then calls this difference procedure and stores the new geometry, but that new geometry doesn't save since the move to 2.2. New code works and the new polygon is clipped/difference, but when we execute the operation if fails to make the change. I can't upgrade to this version until i get this resolved. i am sure it is something simple.

public void Difference(Geometry inDifferenceGeometry)
        {            
            try
            {
                //Get the difference of this ProMap Item minus the inDifferenceGeometry
                if (!inDifferenceGeometry.IsNullOrEmpty())
                {
                    Geometry originalShape = _dataInspector.Shape;
                    Geometry differenceShape = GeometryEngine.Instance.Difference(originalShape, inDifferenceGeometry);

                    _dataInspector.Shape = differenceShape;
                    //create and execute the edit operation
                    // create an edit operation
                    EditOperation differenceOperation = new EditOperation()
                    {
                        Name = "Difference Operation",
                        ProgressMessage = "Working...",
                        CancelMessage = "Operation canceled.",
                        ErrorMessage = "Error In Difference",
                        SelectModifiedFeatures = false,
                        SelectNewFeatures = false
                    };
                    differenceOperation.Modify(_dataInspector);

                    CommitEditOperation(differenceOperation);
                }
            }
            catch (Exception e)
            {
                LogError("Difference", e);
            }

            Log.Debug("ProMapItem - Difference - Finished");
        }

public void CommitEditOperation(EditOperation eo)
        {
            long currentObjectID = OID;
            try
            {
                PMModifiedBy = Settings.CurrentUserName;

                //This line makes sure the OnRowChangeEvent in Module is not retriggered, the OnRowChangeEvent checks this list before it continues
                Module.CurrentlyUpdatingOIDList.Add(currentObjectID);
               
                bool operationResult = eo.Execute();                
            }
            catch (Exception e)
            {
                LogError("CommitEditOperation - " + eo.Name, e);
                throw;
            }
            finally
            {
                Module.CurrentlyUpdatingOIDList.Remove(currentObjectID);
            }
        }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Re: Pro 2.2 issues?

MKa — Wed, 18 Jul 2018 14:09:06 GMT

By watching the Area of the inspector shape, I can see that this line does set the new shape to the difference value

_dataInspector.Shape = differenceShape;

But when i run the following line, that shape.area quickly reverts back to the original value

bool operationResult = eo.Execute();

Re: Pro 2.2 issues?

NarelleChedzey — Thu, 19 Jul 2018 21:00:34 GMT

What is the value of 'operationResult'. when you run the code? If it is false is there a useful string in op.ErrorMessage?

From what you've posted here, it appears that the geometry function is calculating values successfully but it is the edit which fails to be committed. Are you able to edit this same data when using ArcGIS Pro (modify an attribute or use move/rotate/scale to modify the geometry).

Narelle

Re: Pro 2.2 issues?

Wolf — Fri, 20 Jul 2018 00:09:04 GMT

I tried the snippet and it appears to work fine. Do you call the 'Difference' method from within the context of an edit event or simply as a result of inspector.Load ? Also is the data source of the feature in _dataInspector a feature service?

I want to setup the context in my sample to better match your workflow.

Wolf

Re: Pro 2.2 issues?

MKa — Fri, 20 Jul 2018 13:41:22 GMT

I had to rollback to 2.1 as we are moving to a Production Release and are users will have to start on 2.1 until I have time to move to 2.2 and fix the issue. I am able to Move/Resize/Rotate/Add Vertices, but the changes I make to that feature from a feature service as a result of this action, don't seem to save. After i perform one of these Move/Resize/Rotate/Add Vertices actions, my code must sometimes alter that feature to not overlap (Clip) another feature of the same type or to be fully within a different feature (confine). But with 2.2 this functionality doesn't save. I am able to do the intersection/difference edits, but the saves simply don't save when I execute or commit them. I work with the Create/Change functions in my module too, so on create or change event I populate the Feature Service item being created into an inspector like below. The below code is for create, but the change code works in much the same way. Both create and change are not saving my edit actions when i commit them.

(And Sorry, but for some reason the code block option is not available in the reply here?)

protected static async void OnRowCreateEvent(RowChangedEventArgs args)
{
   try
   {
      Inspector inspr = await GetInspectorForRow(args, true);
      ProMapItem pmi = ProMapFactory.GetProMapItem(inspr);

if (pmi != null && Settings.CurrentMapSettings != null)
{

//Make the initial commit to get the field to be visible with the definition query
await pmi.CommitChangesAsync();

         pmi.ShowEditForm = true;
         pmi.HasShapeChanged = true;
         pmi.IsNew = true;

//Run the difference and intersection rules so the polygon is confined or cliped

await pmi.Edit();
}
}
catch (Exception e)
{

}

private static async Task<Inspector> GetInspectorForRow(RowChangedEventArgs args, bool isNewRow)
{
      Inspector inspr = new Inspector();
      try
      {
         long _updateOID = args.Row.GetObjectID();

         //Get the layer of the selected item
         FeatureClass newFC = (FeatureClass)args.Row.GetTable();
         string updateItemName = newFC.GetDefinition().GetAliasName();
         FeatureLayer firstFeatureLayer = FeatureServiceManagement.GetFeatureLayer(updateItemName);

         //Load the inspector
         await inspr.LoadAsync(firstFeatureLayer, _updateOID);
      }
      catch (Exception e)
      {
      }
      return inspr;
}

Re: Pro 2.2 issues?

Wolf — Sun, 12 Dec 2021 08:42:00 GMT

Sorry about the delayed reply. I looked over your snippets of code and tried to implement a sample to perform the same workflow. In my workflow I use RowChangedEvent and RowCreatedEvent subscriptions to make changes to the geometry of the subject row. The workflow looks like this: I modify an existing polygon or create a new one. Once the RowChanged / Created Event a firing, I use the new geometry and union all existing intersects of the new polygon with other polygons in that same layer. I then 'subtract' that union of intersects (if any) with my new geometry and overwrite the sketched geometry. So here is what it looks like in my add-in: First I 'create' a new polygon to my existing layer:

After I complete the sketch my Row Created event kicks in and the add-in logic to change my geometry run to prevent that my newly created geometry doesn't overlay any other polygons. I also update a description field in my new or modified feature to show if the sketched geometry was changed or not.

Hopefully I captured what you do in your add-in. Just in case I did here are some snippets from the sample:

// this is the feature layer that the add-in will process ... needs to be set somewhere in your add-in
private FeatureLayer _workedOnFeatureLayer = null;

// setup event listening ... somewhere in your code
QueuedTask.Run(() => {  
  _onRowChangedEvent = RowChangedEvent.Subscribe(OnRowChangedEvent, _workedOnFeatureLayer.GetTable());
  _onRowCreatedEvent = RowCreatedEvent.Subscribe(OnRowCreatedEvent, _workedOnFeatureLayer.GetTable());
});

// ....

/// <summary>
/// Called for each row change
/// </summary>
/// <param name="args"></param>
private void OnRowChangedEvent(RowChangedEventArgs args)
{
  UpdateStatusText ($@"Row changed: {args.EditType}");
  UpdateRowIfNeeded(args);
}

/// <summary>
/// called for each newly created row
/// </summary>
/// <param name="args">
/// </param>
private void OnRowCreatedEvent(RowChangedEventArgs args)
{
  UpdateStatusText ($@"Row created: {args.EditType}");
  UpdateRowIfNeeded(args);
}

private void UpdateRowIfNeeded (RowChangedEventArgs args)
{
  try  {
    var row = args.Row;
    var geom = row["Shape"] as Geometry;
    var rowCursorOverlayPoly = _workedOnFeatureLayer.Search (geom, SpatialRelationship.Overlaps);
    Geometry geomOverlap = null;
    while (rowCursorOverlayPoly.MoveNext())
    {
      var feature = rowCursorOverlayPoly.Current as Feature;
      var geomOverlayPoly = feature.GetShape();
      if (geomOverlayPoly == null) continue;
      var geomDifference = GeometryEngine.Instance.Intersection(geom, geomOverlayPoly);
      if (geomDifference == null) continue;
      if (geomOverlap == null) {
        geomOverlap = geomDifference;
        continue;
      }
      geomOverlap = GeometryEngine.Instance.Union(geomOverlap, geomDifference);
    }
    if (!geomOverlap.IsNullOrEmpty())
    {
      args.Row["Description"] = "Corrected input polygon";
      row["Shape"] = GeometryEngine.Instance.Difference(geom, geomOverlap);
    }
    else      args.Row["Description"] = "No overlapping polygons found";
  }
  catch (Exception e)  {
    MessageBox.Show($@"Error in UpdateRowIfNeeded for OID: {args.Row.GetObjectID()} in {_workedOnFeatureLayer.Name}: {e.ToString()}");
  }
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Looks like my add-in works for both file and database connections, I will try a feature service tomorrow.

Re: Pro 2.2 issues?

MKa — Sun, 12 Dec 2021 08:42:02 GMT

I have since had to roll back to the 2.1 version as we are in Production now and don't want to upgrade the users version yet. I plan on upgrading and testing again soon. The one thing that i do see that is different is that you are using the row whereas I am loading the inspector with the OID from the Arg. I am thinking it must be something with the Geometry on a non new arg when I load the inspector?

protected static async void OnRowCreateEvent(RowChangedEventArgs args)
        {
            try
            {
                Inspector inspr = await GetInspectorForRow(args);
                ProMapItem pmi = ProMapFactory.GetProMapItem(inspr);

                if (pmi != null && Settings.CurrentMapSettings != null)
                {
                    //pmi.CreatedBy = Settings.CurrentUserName;
                    pmi.PlantCode = Settings.CurrentMapSettings.PlantCode;
                    pmi.HarvestYear = Settings.CurrentMapSettings.HarvestYear;
                    pmi.HarvestTrimester = Settings.CurrentMapSettings.HarvestTrimester;
                    pmi.MaterialGroup = Settings.CurrentMapSettings.MaterialGroup;

                    //Override of Created/Modified
                    pmi.PMCreatedBy = Settings.CurrentUserName;
                    pmi.PMModifiedBy = Settings.CurrentUserName;

                    //Make the initial commit to get the field to be visible with the definition query
                    await pmi.CommitChangesAsync();

                    pmi.ShowEditForm = true;
                    pmi.HasShapeChanged = true;
                    pmi.IsNew = true;
                    await pmi.Edit();
                }
            }
            catch (Exception e)
            {
                ProMapBlackLogWriter.LogError("ProMapBlackModule - onRowCreateEvent", e);
            }
        }

private static async Task<Inspector> GetInspectorForRow(RowChangedEventArgs args)
        {
            Inspector inspr = new Inspector();
            try
            {
                long _updateOID = args.Row.GetObjectID();

                //Get the layer of the selected item
                FeatureClass newFC = (FeatureClass)args.Row.GetTable();
                string updateItemName = newFC.GetDefinition().GetAliasName();
                FeatureLayer firstFeatureLayer = FeatureServiceManagement.GetFeatureLayer(updateItemName);

                //Load the inspector                
                await inspr.LoadAsync(firstFeatureLayer, _updateOID);
            }
            catch (Exception e)
            {
                ProMapBlackLogWriter.LogError("ProMapBlackModule - GetInspectorForRow", e);
            }
            return inspr;
        }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Re: Pro 2.2 issues?

Wolf — Sun, 12 Dec 2021 08:42:05 GMT

I took my sample code that I used to duplicate your workflow and published the sample on 'community samples' GitHub repo here: Modify Newly Added Features. Hopefully this sample helps when you refactor the code for 2.2. There are a few issues that I would like to highlight in the ProConcepts Editing document, specifically in the Row Events section at the end of the document:

1. "The row events are published during the execution of the edit operation (whereas the EditCompletedEvent is published after the entire edit operation has completed)." This means that the row event intercepts your row creation/update before the transaction is completed, you can still cancel any changes from within any row event. You cannot commit any data changes while you are processing any row events which I think is what you do in your code here:

//Make the initial commit to get the field to be visible with the definition query
await pmi.CommitChangesAsync();‍‍

If your intend is to display a newly created feature that satisfied the current 'definition query' on that layer, you should use an appropriate 'editing / creation template' that contains valid values so that the 'definition query' results are true (hence your new feature is shown on the map view) from the get-go. You can make changes to the args.row fields directly if need be (see the sample) and you can call .Store() on the row to save these changes, but this will result in a recursive row event (again see the sample for details).

2. "If you need to edit additional tables within the RowEvent you must use the ArcGIS.Core.Data API to edit the tables directly. Do not use a new edit operation to create or modify features or rows in your RowEvent callbacks." I think I saw your code snippets using an another EditOperation in one of the functions that are instantiated from the row events. In 2.2 this will not work. Instead, as indicated by the documentation, you must use the ArcGiS.Core.Data API to change other data sources directly (in the sample I show this when I update the tracking/logging table).

Hopefully this will help you out.

Wolf

Re: Pro 2.2 issues?

MKa — Fri, 03 Aug 2018 14:30:19 GMT

So this is a drastic change then? I cannot call apply changes from within a row create/row change event any longer? Will the change you suggest work in 2.1? Or do we have to make all these changes in 2.2 sdk and deploy to 2.2 installation. My production code is out there in 2.1 and we are still developing against 2.1, so my question is will the code changes made to work in 2.2, still work in 2.1. This will require some effort to get this upgraded.

My polygon features rely and other polygon features of a different class. Some must be confined within a polygon of a different type, some cannot intersect a polygon of a different type. Their attributes and shapes are changed accordingly using applyasync. So imagine if I shrunk a "Parent" polygon, the child polygon of a different feature lies within that polygon. When that parent polygon shrinks, the child polygon must shrink itself to stay confined, and in most cases update a number of area and location attributes.

You are saying that I will need to update these values in a different way, whereas before I just told the underlying OID to basically apply changes and the row change event would take care of the work for that Object. You are saying I can't call row change from withing a row change?

Re: Pro 2.2 issues?

Wolf — Tue, 07 Aug 2018 17:58:10 GMT

Hi M,

Sorry for the late reply, but I checked back with some of my colleagues to make sure that my findings were correct. So to answer your question: "So this is a drastic change then?" According to the documentation "starting a new EditOperation within a Row Event" is not supported in 2.2 and this was also true in 2.1, so this is not a change in 2.2. As to why this worked for you in 2.1 I can only speculate, but when I tried this workflow in my sample add-ins in 2.1 I was not able to get it to work reliably.

That being said let me answer your last question: "You are saying I can't call row change from within a row change?" If you look at the sample ModifyNewlyAddedFeatures that I published it includes the "enable Store()" option which calls .Store() on the Row Event's subject row. Calling Store() from within a Row Event can cause a Row Event to be triggered recursively and you can use the args.Guid parameter to determine re-entrance as illustrated by the sample.

Finally to address your 2nd paragraph "My polygon features rely and other polygon features of a different class." I will modify my sample code so that creating or modifying a feature leads to changes in other features in order to emulate your requirements and post the updated sample.

Re: Pro 2.2 issues?

MKa — Wed, 15 Aug 2018 15:18:48 GMT

I still haven't gotten back to this, but what you mention above about using the args.Guid to determine reentrance is exactly what I do. When we get to upgrading our version to 2.2 I will be able to work on this more. But I am still suspecting that it has something to do with assigning the Geometry to an inspector on the Row when I load it from change event arg. I think the Shape is not getting loaded correctly to my inspector and is somehow using the old shape on for the Row, and not the updated shape?

long _updateOID = args.Row.GetObjectID();

//Get the layer of the selected item
FeatureClass newFC = (FeatureClass)args.Row.GetTable();
string updateItemName = newFC.GetDefinition().GetAliasName();
FeatureLayer firstFeatureLayer = FeatureServiceManagement.GetFeatureLayer(updateItemName);

//Load the inspector
await inspr.LoadAsync(firstFeatureLayer, _updateOID);

Re: Pro 2.2 issues?

MKa — Sun, 12 Dec 2021 08:42:08 GMT

Above you say

"I think I saw your code snippets using an another EditOperation in one of the functions that are instantiated from the row events. In 2.2 this will not work. "

This has to be my issue. Within each create or update row event, my object tells itself to clip based on another shape of a certain type. In that clip function is the difference command. That difference command uses the edit operation modify and calls a commit operation to do the execution. The commit operation keeps track of the OID so that the row change isn't fired again. How do I go about switching from the edit operation code below, to committing my geometry changes for my inspector in the row events like you mention. I need my geometry/shape change to be reflected. But I don't see in your example how I can do this?

//Gets the Difference of this Item minus an input Geometry
public void Difference(Geometry inDifferenceGeometry)
{
   LogWriter.Log.Debug("   Item - Difference - Entered");

   try
   {
      //Get the difference of thisItem minus the inDifferenceGeometry
      if (!inDifferenceGeometry.IsNullOrEmpty())
      {
         Geometry originalShape = _dataInspector.Shape;
         Geometry differenceShape = GeometryEngine.Instance.Difference(originalShape, inDifferenceGeometry);

         _dataInspector.Shape = differenceShape;


         //create and execute the edit operation
         // create an edit operation
         EditOperation differenceOperation = new EditOperation(){
                    Name = "Difference Operation",
                    ProgressMessage = "Working...",
                    CancelMessage = "Operation canceled.",
                    ErrorMessage = "Error In Difference",
                    SelectModifiedFeatures = false,
                    SelectNewFeatures = false
               };

           differenceOperation.Modify(_dataInspector);

               
           CommitEditOperation(differenceOperation);
      }
  }
  catch (Exception e)
  {
    LogWriter.LogError("   Item - Difference", e);
  }
}

public void CommitEditOperation(EditOperation eo)
{
  long currentObjectID = OID;
  try
  { 
     PMModifiedBy = Settings.CurrentUserName;
     Module.CurrentlyUpdatingOIDList.Add(currentObjectID);
     LogWriter.Log.Debug("   Item - CommitEditOperation - Started " + eo.Name);
 
//AT THIS POINT MY SHAPE IS THE CORRECT NEW ARE, BUT THE Execute() CHANGES THAT back to the original shape

      bool operationResult = eo.Execute();
      LogWriter.Log.Debug("   Item - CommitEditOperation - Finished " + eo.Name);
  }
  catch (Exception e)
  {
    LogWriter.LogError("   Item - CommitEditOperation - " + eo.Name, e);
     throw;
  }
  finally
  {
    Module.CurrentlyUpdatingOIDList.Remove(currentObjectID);
  }
}
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Re: Pro 2.2 issues?

MKa — Sun, 12 Dec 2021 08:42:10 GMT

I just attempted to remove the edit operation and just use apply on the inspector. This also fails to update the geometry? How do I update the geometry of the inspector? If I catch the Arg in the Row Change Event, after I call Apply, the area value has reverted back to the pre difference value too?

//Gets the Difference of this Item minus an input Geometry
public void Difference(Geometry inDifferenceGeometry)
{
   LogWriter.Log.Debug("   Item - Difference - Entered");

   try
   {
      //Get the difference of thisItem minus the inDifferenceGeometry
      if (!inDifferenceGeometry.IsNullOrEmpty())
      {
         Geometry originalShape = _dataInspector.Shape;
         Geometry differenceShape = GeometryEngine.Instance.Difference(originalShape, inDifferenceGeometry);

         _dataInspector.Shape = differenceShape;

           if (_dataInspector != null)
            {
                long currentObjectID = OID;
                try
                {
                    ProMapBlackModule.CurrentlyUpdatingOIDList.Add(currentObjectID);
                    PMModifiedBy = Settings.CurrentUserName;

                         //AFTER THE APPLY, THE VALUE reverts back to the Original (Pre Difference Area???)
                    _dataInspector.Apply();
                }
                catch (Exception e)
                {
                    ProMapBlackLogWriter.LogError("ProMapItem - CommitChanges - " + MemberName, e);
                    throw;
                }
                finally
                {
                    ProMapBlackModule.CurrentlyUpdatingOIDList.Remove(currentObjectID);
                }
            }
      }
  }
  catch (Exception e)
  {
    LogWriter.LogError("   Item - Difference", e);
  }
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Re: Pro 2.2 issues?

MKa — Wed, 05 Sep 2018 21:12:33 GMT

I have just confirmed that when I make changes to an inspector and call apply or applyasync, those changes do not come through with the "Args" on the OnRowChangeEvent. Is there some other shape I need to change on the inspector I need to call before I call Apply()?

To test this, set up a Row Change on your module. Then from another piece of code, update an inspectors shape to another shape (i am using a feature service). The areas should be different at this point. Note the Area of the shape at this point, then apply() that change.

This will then trigger the row change event in the module. In the change event, catch the Arg immediately and look at its shape area value, it should be the same as your inspector, but that shape has reverted back to the shape from before you made the original change.

There is something going on here for sure? The inspector shape is not updating or reverting somehow

Re: Pro 2.2 issues?

MKa — Sun, 12 Dec 2021 08:42:13 GMT

I think I have a work around for this issue, but don't understand why I have to do this. The problem with this, is that when .Apply is done to an Inspector that has its shape changed, that change is not happening or saved. Is anyone else experiencing this? Apply and Apply async don't update my inspector shape in the database, it rolls the change back. All other attributes appear to update, but shape rolls back.

My workaround is to create a static geometry variable in my module. This Geometry variable needs to be set to a geometry value that you want to change for an inspector somewhere. That way, when on the OnChange event comes in, the arg can set its shape to this value. This is the only way I can get this to work. This has to be a bug of some kind

I used to be able to set my geometry for an inspector and call Apply Async

_dataInspector.Shape = NewBufferShape;
await _dataInspector.ApplyAsync();‍‍‍

in 2.2 the above won't work any longer, as the Apply on the inspector doesn't appear to save the shape anymore. You can test this by putting breakpoint in the OnChange event of the module and seeing that the area on the arg is not the same as the area on the inspector. You can also change the shape of the inspector, note the shape area, apply changes and check the shape area again right after apply is done. It will have rolled back.

So the work around has to be to set up a static variable to set on the module to force the Arg to set the new geometry

//Layer object code on how to update
Module.CurrentlyUpdatingGeometry = _dataInspector.Shape;
await _dataInspector.ApplyAsync();
Module.CurrentlyUpdatingGeometry = null;


//Module Code
public static Geometry CurrentlyUpdatingGeometry;
protected static async void OnRowChangeEvent(RowChangedEventArgs args)
{           
   if (!CurrentlyUpdatingGeometry.IsNullOrEmpty())
   {
      args.Row["Shape"] = CurrentlyUpdatingGeometry;
   }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
.
.
.
.
.‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Re: Pro 2.2 issues?

CharlesMacleod — Sun, 12 Dec 2021 08:42:16 GMT

Using the row, passed as the argument to the row event, as you illustrate above is the correct pattern. Use of the inspector to apply an edit in any of the row events should not be attempted (whether it worked previously or not).

 
 private void RowEvent(....

 //this is correct
 args.Row["Shape"] = CurrentlyUpdatingGeometry;
 args.Row.Store();

 //this is not. It triggers another edit operation
 insp["Shape"] = CurrentlyUpdatingGeometry;
 insp.Apply(); //<-- attempts to execute another edit operation‍‍‍‍‍‍‍‍‍‍

Note that row events are fired during the store* on the underlying geodatabase - in other words, before the store has completed but after it has started. Therefore, any changes you are applying in an edit operation (that has triggered a row event) have not yet been committed and are in flight. This is why, in most cases, they are cancel-able regardless of the transaction type (short or long). It is also why, if you re-access the row via the layer or the feature class, "in flight", you get the "original" value.

*Non-versioned feature services on a create fire the row event after the store on the server.

Below is a code example you can play with to test this behavior. I am running it against an editable hosted point feature service: The code creates a feature and then moves it to another location. The feature shape is output at various instances within the transaction - Before, During ("in flight"), and After. This is the output:

Create location: 60546084,2112494 <-- start location
Create oid: 44

Intended Move location: 60546634,2113044  <-- what we pass to modify
INFLIGHT: Move location: 60546634.0001205,2113043.99987471 <-- from Row["SHAPE"] in event
DATABASE: Move location: 60546083.9999188,2112494.00000116 <-- from GDB in event
Final Move location: 60546634.0001205,2113043.99987471  <-- final after event (and commit)
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Notice that the "move" location in the event ("INFLIGHT") within the "modify-ing" row ("args.Row" or "rc.Row" in my example), is the intended final location. Notice that the location I retrieve from the database in the event is not. It is still the "pre" location as the database has not yet been modified and will not be modified until after the execute() has concluded successfully. After execute(), re accessing the database gets the (correct) final location.

 internal class TestRowEvent : Button
  {
    private SubscriptionToken _token = null;
    private double _x = 60546084.0;
    private double _y = 2112494.0;
    private double _delta = 550.0;

    protected async override void OnClick()
    {
      await QueuedTask.Run(() => {
        var fs_layer = MapView.Active.Map.GetLayersAsFlattenedList().OfType<FeatureLayer>()
          .First(fl => fl.Name == "<name of layer here>");

        var editOp = new EditOperation();
        editOp.Name = $"Create {fs_layer.Name}";
        editOp.SelectNewFeatures = true;
        //make the locations
        var pt = MapPointBuilder.CreateMapPoint(_x, _y, fs_layer.GetSpatialReference());
        Dictionary<string, object> attributes = new Dictionary<string, object>();
        attributes["SHAPE"] = pt;
        attributes["...."] = "value 1";
        //etc

        long _newoid = -1;
        editOp.Create(fs_layer, attributes, (oid) => _newoid = oid);
        editOp.Execute();
        editOp = null;

        System.Diagnostics.Debug.WriteLine($"Create location: {_x},{_y}");
        System.Diagnostics.Debug.WriteLine($"Create oid: {_newoid}");

        //move the feature
        pt = MapPointBuilder.CreateMapPoint(_x + _delta, _y + _delta, fs_layer.GetSpatialReference());

        editOp = new EditOperation();
        editOp.Name = $"Move {fs_layer.Name}";
        editOp.SelectModifiedFeatures = true;
        editOp.Modify(fs_layer, _newoid, pt);
        System.Diagnostics.Debug.WriteLine($"Intended Move location: {_x + _delta},{_y + _delta}");

        //show the geometry "in-flight"...
        _token = ArcGIS.Desktop.Editing.Events.RowChangedEvent.Subscribe((rc) =>
        {
          var inflight_pt = rc.Row["SHAPE"] as MapPoint;
          System.Diagnostics.Debug.WriteLine($"INFLIGHT: Move location: {inflight_pt.X},{inflight_pt.Y}");
          //pull location from the database
          using (var rowcursor = fs_layer.GetSelection().Search())
          {
            rowcursor.MoveNext();
            var db_pt = rowcursor.Current["SHAPE"] as MapPoint;
            System.Diagnostics.Debug.WriteLine($"DATABASE: Move location: {db_pt.X},{db_pt.Y}");
          }
          ArcGIS.Desktop.Editing.Events.RowChangedEvent.Unsubscribe(_token);
          _token = null;

        }, fs_layer.GetTable());

        editOp.Execute();

        //get the modified feature
        var insp = new Inspector();
        insp.Load(fs_layer, _newoid);
        var move_pt = insp["SHAPE"] as MapPoint;
        System.Diagnostics.Debug.WriteLine($"Final Move location: {move_pt.X},{move_pt.Y}");

      });
    }
  }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Re: Pro 2.2 issues?

MKa — Sun, 12 Dec 2021 08:42:19 GMT

So i should be have been using a rowcursor this whole time and not the inspector. Much like we use to do in arcobjects? I found the inspector very easy to use, and had to use the OID to prevent reentry into the change event, but other than that it worked great. This is triggered when a user creates a feature. Basically I send the inspr to my factory and it does all the work. So I should remove the inspector and switch it to the row? And use store instead of the apply methods on Inspector?

protected static async void OnRowCreateEvent(RowChangedEventArgs args)
        {
            try
            {
                Inspector inspr = await GetInspectorForRow(args, true);
                PMItem pmi = PMFactory.GetPMItem(inspr);

                if (pmi != null && Settings.CurrentMapSettings != null)
                {                    
                    pmi.PlantCode = Settings.CurrentMapSettings.PlantCode;
                    pmi.HarvestYear = Settings.CurrentMapSettings.HarvestYear;
                    pmi.HarvestTrimester = Settings.CurrentMapSettings.HarvestTrimester;
                    pmi.MaterialGroup = Settings.CurrentMapSettings.MaterialGroup;

                    //Override of Created/Modified
                    pmi.PMCreatedBy = Settings.CurrentUserName;
                    pmi.PMModifiedBy = Settings.CurrentUserName;

                    //Make the initial commit to get the field to be visible with the definition query
                    await pmi.CommitChangesAsync();

                    pmi.ShowEditForm = true;
                    pmi.HasShapeChanged = true;
                    pmi.IsNew = true;
                    await pmi.Edit();
                }
            }
            catch (Exception e)
            {
                LogWriter.LogError("PMBlackModule - onRowCreateEvent", e);
            }
        }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Re: Pro 2.2 issues?

CharlesMacleod — Thu, 06 Sep 2018 18:15:22 GMT

Correct. Within the row events you must use Row.Store to apply changes. You will still have to deal with re-entrancy caused by Store.