EditCompletedEventArgs and Deletes

[coryeicher]

Hi,

We are interested in accessing attributes of deleted feature(s) when handling `EditCompletedEvent`. Just checking in, is the guidance in this post is still accurate with the release of ArcGIS Pro 3.0? The post recommends to handle `RowDeletedEvent` since deleted feats are not available in this (or any) edit event.

I've perused these version 3.0 links and not found anything different...

• EditCompletedEventArgs Class
• https://github.com/Esri/arcgis-pro-sdk/wiki/ProConcepts-3.0-Migration-Guide#arcgisdesktopeditingdll
• https://www.esri.com/arcgis-blog/products/arcgis-pro-net/mapping/whats-new-in-the-arcgis-pro-sdk-3-0...

.... but want to make sure I haven't missed anything. Again, is the recommendation still to handle `RowDeletedEvent` if we want access to deleted features' attributes in the ArcGIS Pro 3.0 SDK? 

Thanks,

-Cory

[John_Jones · Accepted solution]

Cory,

Yes this advice is still valid.  In summary, the EditCompleted fires after an edit is complete (after the row has been deleted) its primary use is to inform listeners with hints about what cached state may have been invalidated by the issue (with row level granularity when possible).

RowDeleted is fired earlier, while the edit is still in progress, and as such has access to the GDB objects being modified (in this case deleted) to investigate the attributes.  Later on this row won't exist in the database and only the ObjectID will be available to provide information about the deleted row. 

RowDeleted requires the listener to specify which table(s) they are interested in prior to the edits occurring (and later disconnecting) while EditCompleted fires generally on every edit with information about any data being edited.

[coryeicher]

Thank you. Appreciate the confirmation.

For context, in our scenario we are wanting to trigger downstream changes, specifically deleting non-spatial rows from related table(s). We're avoiding use of OIDs as keys, and generally looking to keep it as simple as possible.

We may also look at using composite relationship classes for our use case.

Thanks again,

-Cory

[John_Jones]

In addition to composite relationship classes you may want to investigate using a Attribute rule (constraint with trigger on Delete) to embed the logic in an Arcade expression that will be triggered from all clients not only Pro (with your Add-In extension running).