Pro analog to ArcMap's OnStopEditing event?

3633
6
Jump to solution
11-12-2015 02:28 PM
Mark_AOppedahl
New Contributor

I'm trying to port an ArcMap extension to Pro and can't find the event I need. The old code uses OnStopEditing to know when an edit session is saved, at which time it enumerates the committed row inserts, edits, and deletes, and notifies an external application of the changes. The Pro SDK seems only to have EditCompletedEvent, which fires after each individual edit operation. The problem is the user could undo the edit operation or discard it by not saving the session, in which case the external app must not be notified of the change.

So is there any way in Pro to detect the edit session is being saved, and get a list of the committed changes (features affected, before and after values, etc.)?

0 Kudos
1 Solution

Accepted Solutions
SeanJones
Esri Regular Contributor

Hi Mark,

The start and stop editing events from ArcMap have not been exposed in Pro in the current version.

You can get information on row events within an edit session through the row changed events, but in your case it could be moot without knowing the edit session boundaries.
The row changed event args return a row that can be queried for properties such as HasValueChanged and GetOriginalValue. In ArcMap I presume you use the IDataChangesEx Interface?

We’ll look at these events in a future release. Are there any other editing events your extension relies on?

View solution in original post

0 Kudos
6 Replies
SeanJones
Esri Regular Contributor

Hi Mark,

The start and stop editing events from ArcMap have not been exposed in Pro in the current version.

You can get information on row events within an edit session through the row changed events, but in your case it could be moot without knowing the edit session boundaries.
The row changed event args return a row that can be queried for properties such as HasValueChanged and GetOriginalValue. In ArcMap I presume you use the IDataChangesEx Interface?

We’ll look at these events in a future release. Are there any other editing events your extension relies on?

0 Kudos
MarkOppedahl
New Contributor

Hi Sean,

Thanks for you quick response. Here are the session-level events we're using in ArcMap:

  • Events.OnStartEditing. Here we compare Editor.EditWorkspace to the workspaces of interest to the external application. Subsequent processing only occurs when the user is editing data relevant to the external app.
  • Events2.OnBeforeStopEditing. If the edit session is being saved (not discarded) and the workspace is of interest, the code compiles a list of inserted/updated/deleted features. The code gets the changes with WorkspaceEdit2.get_EditDataChanges(esriEditDataChangesType.esriEditDataChangesWithinSession), then calls ExtractEx on the result using the different esriDifferenceType values.
  • Events2.OnStopEditing. If a change list was created in the prior step, here is where the code sends the list to the external app through that app's REST API.

Besides the session-level events, our ArcMap extension also uses row-level events to validate feature attributes real-time and do some on-the-fly conflict resolution.

  • Events.OnChangeFeature/OnCreateFeature/OnDeleteFeature. The extension monitors these events to enforce business rules on certain attributes. If a rule is violated, the user's change is undone, and the user is informed why. These are rules that can't be enforced by simple geodatabase constraints on the attributes. The code uses the row's IRowChanges interface to find out what's been edited and compare new and old values.
  • Events.OnConflictsDetected. Conflict resolution is necessary because when the user saves an edit session, and OnStopEditing then sends a change list to the external app, this can trigger the external app to use the ArcGIS Server REST API to make its own changes to the feature class. If the external app changes a feature that's still part of the edit session, there are conflicts to resolve, and the OnConflictsDetected handler merges the external changes with the user changes in the current session. The code uses the IVersionEdit4 interface of the Editor.Editworkspace to get the pieces it needs.

I can understand this is all probably above and beyond what a typical Pro add-in is expected to do. But without this level of capability in the Pro SDK, we'll just have to hold off on porting our extension to Pro.

-Mark

JordanFollett
New Contributor

Has there been any progress on extending the on start editing to Pro?

0 Kudos
SeanJones
Esri Regular Contributor

Not directly but a few things have been added to 2.3

ArcGIS.Desktop.Editing.Events.EditCompletingEvent is the equivalent OnBeforeStopOperation

ArcGIS.Desktop.Core.Project.EditedDatastores returns the data stores (workspaces) that have pending edits which have not been saved.

ArcGIS.Desktop.Editing.Events.EditCompletedType now includes post and reconcile.

The OnStopEditing equivalent would be the EditCompleted event where the EditCompletedType would be either save or discard. Both of these stop the edit session. EditCompletedEventArgs provides the changes during an individual editoperation. Additionally the rowevents will also fire during the operation.

There's no equivalent for OnStartEditing. An editoperation will start an edit session if there isnt one already going during Execute but it wont know whats changed until its completed.

The IDataChanges equivalent is in progress.

Conflict support is currently limited.

JordanFollett
New Contributor

So for the edit operation, Will the edit session be able to fire something to let us know a user is starting to edit a version? I ask because there are things we check for when a user tries to start editing. 

0 Kudos
SeanJones
Esri Regular Contributor

Hi Jordan,

Without a formal start editing experience the best place to do this for custom tools would be the tool activation event. You could do your layer checks there and message appropriately. 

For core tools such as reshape its trickier. You would have to listen to row changes on the layer(s) then work out the version and cancel the edit if it wasn't correct. Unfortunately to the user it looks like they can do the edit, until it fails. Rather than listening to row events, one thing we can add here for 2.4 is more information on whats about to happen in the editcompleting event, being the list of layers and features being edited but before the commit.

0 Kudos