topic Re: Check features after edit in ArcGIS Pro SDK Questions

Check features after edit

mody_buchbinder — Thu, 01 Dec 2022 13:41:24 GMT

I am trying to get the OnEditCompleted event and do some checks (is the operation allowed) and actions (calc some default values).

The basic code is below. I have a few questions:

1) Do I need to get the OnRowCreated event too or this event is covering the same operations. Keep in mind that I have to check features added by GP tools (like append).

2) From my debug it looks that even this event is called multiply times with no reason - what can I do about it?

3) I could not find the way to abort the transaction. I could not find something like RowChangedEventArgs.CancelEdit

I used EditCompletedEventArgs.FromException but it create Exception and does not end transaction.

Thanks

Mody

protected Task onEditCompleted(EditCompletedEventArgs args) { // check features one by one string message = ""; Dictionary<MapMember, List<long>> createSelset = args.Creates.ToDictionary(); foreach (var v in createSelset) { QueryFilter queryFilter = new QueryFilter(); queryFilter.ObjectIDs = v.Value; FeatureLayer featureLayer = v.Key as FeatureLayer; using (FeatureClass featureClass = featureLayer.GetFeatureClass()) { using (RowCursor cursor = featureLayer.GetFeatureClass().Search(queryFilter)) { Feature currentFeat = null; while (cursor.MoveNext()) { currentFeat = (Feature)cursor.Current; bool res = CheckFeatureCreate(currentFeat, out message); if (res == false) { return Task.FromException(new Exception(message)); } res = HandleFeatureCreate(currentFeat); if (res == false) { return Task.FromException(new Exception("Problem with calc values")); } } } } }

Re: Check features after edit

RichRuh — Thu, 01 Dec 2022 15:32:36 GMT

Hi Mody,

I'm not an expert on editing events, so I cannot really comment on your code.

Just wanted to ask if you'd had a chance to look into attribute rules? These are rules written in Arcade script that fire during the editing process. You can write constraint rules, which allow checks to take place before an edit is accepted, and calculation rules, which fill in data values.

It sounds like a perfect match for your requirements, although there many be other circumstances which prevent them from working for you.

--Rich

Re: Check features after edit

CharlesMacleod — Thu, 01 Dec 2022 17:41:01 GMT

Mody, EditCompletedEvent fires _after_ the fact, when the transaction has completed so it cannot be cancelled as it is not longer running. You may want to look at the EditCompletingEvent which also provides a CancelEdit capability. It is explained here: https://github.com/esri/arcgis-pro-sdk/wiki/ProConcepts-Editing#editcompletingevent.

API Reference: https://pro.arcgis.com/en/pro-app/latest/sdk/api-reference/topic20522.html

Re: Check features after edit

mody_buchbinder — Sun, 04 Dec 2022 06:40:57 GMT

Good answer by Charlie (as usual).

The limit we try to force is that the user can not add/change/delete more then X number of features in one operation.

I do not see any way to do it using attribute rules since they work one by one.

In face we cannot use OnRowCreated for the same reason.

Do you see any reason to subscribe to OnRowCreate if we subscribe to EditCompletingEvent - is there any case that not both of them is called?

Thanks

Re: Check features after edit

CharlesMacleod — Mon, 05 Dec 2022 17:39:48 GMT

Hi Mody, I think it just depends on what your workflow requirements are. The EditCompletingEvent, imo, could be useful if you are tracking specific edit operations (typically that u initiate) and u are doing some broad-based validation or even auditing/logging.

The ROW events are much more granular than the EditCompletingEvent event - they will fire any time an edit occurs against a dataset (for which u register for events). They also contain the row being edited which makes them useful for "final" validation of a specific feature or other business logic that wants to change an attribute value before the "Store" completes.

The event to be the most judicious with will be the ROW event given how frequently it could fire during an edit (that spans multiple rows and multiple datasets - if u r registered against many datasets).