Select to view content in your preferred language

EditCompletedEventArgs and Deletes

768
3
Jump to solution
08-16-2022 12:04 PM
coryeicher
Frequent Contributor

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...

.... 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

CORY EICHER
www.eichcorp.com
cory@eichcorp.com
0 Kudos
1 Solution

Accepted Solutions
John_Jones
Regular Contributor

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.

View solution in original post

0 Kudos
3 Replies
John_Jones
Regular Contributor

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.

0 Kudos
coryeicher
Frequent Contributor

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

CORY EICHER
www.eichcorp.com
cory@eichcorp.com
0 Kudos
John_Jones
Regular Contributor

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).

0 Kudos