Bug
'EditCompletedEventArgs' shows zero features created and modified after using the Create Point and Edit Point tools in ArcGIS Pro's Location Referencing tab.
| Bug ID Number | BUG-000113721 |
|---|---|
| Submitted | May 4, 2018 |
| Last Modified | June 5, 2024 |
| Applies to | ArcGIS Pro SDK for .NET |
| Version found | 2.0 |
| Operating System | Windows OS |
| Operating System Version | 10.0 64 Bit |
| Status | Will Not Be Addressed |
Additional Information
This is as designed. The reason for the unexpected behavior is coming from two different sources of error. The linear referencing code making the edit calls IExternalEditCallbackContext::InvalidateTable to invalidate the entirety of the table in which a point was created (as well as another modified table in which a feature was changed). The editor purposefully interprets this to mean that the table may have changed in unpredictable ways (perhaps the calling code disabled event firing for performance) and the results of listening to geodatabase object events may not reflect the extent to which the table had been modified. As a result the properties of the EditCompletedEventArgs is escalated, and broadcasted to managed listeners to (similarly to how the editor internally invalidates all viewer tiles for this table, a rather costly operation for a spatially confined edit such as this one) interpret the event as any features in the concerned layers (referencing these tables) may have changed and to more exhaustively respond to the event to invalidate any caches necessary.The add-in supplied in the reproduction case is making a faulty assumption that if the list of created or modified features is zero, it just reports this without checking EditCompletedEventArgs.InvalidateAllMembers and relaying the information present in that property to the user in the modal dialog they show.As a result this is considered as designed from an Editing perspective. To achieve the desired results the Linear referencing code should be re-written to avoid calling IExternalEditCallbackContext::InvalidateTable and instead call the more specific IExternalEditCallbackContext::InvalidateRow which confines the amount of work done to invalidate the viewer to just the modified feature. (This is how the built-in editor provided tools work thus the issue is not reproducible with them.) Ideally, for modified features this would be called both before and after the changes were made to the row so if the set of viewer tiles is changed by the edit that both sets are properly accounted for in editing's messaging to the viewers.Editing should also clarify existing SDK documentation as while this specific API is for internal use only the same general issues come up with EditOperation.Callback's use of EditOperation.IEditContext's Invalidate methods.Steps to Reproduce
Bug ID: BUG-000113721
Software:
- ArcGIS Pro SDK for .NET
Get notified when the status of a bug changes
Discover more on this topic
Search for related information
Find training related to this topic
Explore ideas and give feedback
Get help from ArcGIS experts
Download the Esri Support App