This document is archived and information here might be outdated.  Recommended version.


Responding to feature or row edits (ArcObjects .NET 10.8 SDK)
ArcObjects Help for .NET developers > ArcObjects Help for .NET developers > Developing with ArcGIS > Learning ArcObjects > Editing data > ArcGIS for Desktop editing for developers > Working with editing events > Responding to feature or row edits

Responding to feature or row edits


Summary
This topic describes the events the editor provides that allow developers to listen and respond to changes when features are created, updated, or deleted.

In this topic


Feature editing events

Some of the most common events that developers working with the editor use is those that are triggered when a feature or row changes, providing an audit trail documenting attributes of the edit, such as the creation or modified date, and the user who last updated the feature. The editor provides the following events that provide information about these changes:
The events listed previously are not specific to features; these events are also fired when changes are made to non-spatial records (rows). All concepts discussed in this topic apply to both features and rows.
When listening to these events, it is important that no attempts are made to change the feature or abort the edit operation inside these handlers. Because there might be several customizations listening to the same event, the state must remain static to allow each client listening to these events to process it completely before the edit operation's state is changed.

Feature events and cursors

Most tools and commands that create features inside the editor utilize IFeature.Store to commit the changes back to the geodatabase. However, in some cases for performance reasons, some tools or commands use an insert cursor. One of the ramifications of utilizing an insert cursor in lieu of IFeature.Store is that feature creation or update events are not fired.
The following are tools in the editor user interface (UI) that use insert cursors:
  • Planarize lines command
  • Auto-complete polygon tool
  • Construct Features command
  • Create 2-point lines command (coordinate geometry [COGO])
If you are developing an editor extension that relies on receiving these events to perform subsequent processing, the workspace can be forced to use IFeatureClass.CreateFeature and IFeature.Store instead of an insert cursor by executing IWorkSpaceEditControl.SetStoreEventsRequired.
The preferred time to execute this method is inside the OnStartEditing event handler. Adding the following code example to the start editing event forces the use of IFeatureClass.Create and IFeature.Store for all the simple classes in the workspace:
[C#]
IWorkspaceEditControl pWorkspaceEditControl=m_editor.EditWorkspace as
    IWorkspaceEditControl;
pWorkspaceEditControl.SetStoreEventsRequired();
[VB.NET]
Dim pWorkspaceEditControl As IWorkspaceEditControl
Set pWorkspaceEditControl=CType(m_editor.EditWorkspace, IWorkspaceEditControl)
pWorkspaceEditControl.SetStoreEventsRequired()

Alternative methods for tracking feature edits

An alternative method to listening for each individual create, update, or delete of a feature is to ask the data source for all edits (creates, updates, and deletions) for an edit operation or for the edit session. For more information on how to retrieve edits using this, see Obtaining changes made in the current edit session.
This capability is only available for Geodatabase data sources; it is not supported for shapefiles. If events are required, consider listening for OnCreateFeature, OnUpdateFeature, and OnDeleteFeature in conjunction with IWorkSpaceEditControl.SetStoreEventsRequired as previously discussed in this topic.






Development licensing Deployment licensing
ArcGIS Desktop Advanced ArcGIS Desktop Advanced
ArcGIS Desktop Standard ArcGIS Desktop Standard
ArcGIS Desktop Basic ArcGIS Desktop Basic