In our environment, we prefer to have users Enable/Disable editing from the Edit tab. We are using traditional versioning in ArcPro 3.1.4. We have found when using Calculate Geometry on the Attribute Table to calculate lengths the update occurs in the table and the "Save" button remains greyed out. If a user, does not physically disable the Edit Session or perform other edits that require the "Save" button, the changes do not stick. These changes could either automatically save so that if a user closes out of their project without disabling the "Edit" button the edits are still saved or require the "Save" button to commit the changes to match normal editing workflow.
We experience the same issue as mejohnson22. Calculate geometry does not mark the features as having been edited and edits are lost if we stop editing without making another edit. This appears to be a bug. We are at 3.2.2.
For tracking purposes: this is registered as defect ENH-000157071, Public Status = In Product Plan
"Calculate Geometry does not have an undo toggle and will not be listed in the save edits operation when running in an edit session"
This is implemented in ArcGIS Pro 3.4. The Calculate Geometry Attributes tool has an enable undo button. FYI, this feature has also been added to custom script and model tools.
Go to Your Ideas in ArcGIS Pro 3.4 to see other ideas implemented this release and check out the What's New help to learn about everything that is new and improved in ArcGIS Pro 3.4.
I have been in discussion lately with @CharlesMacleod on a similar topic and he pointed me to this idea / enhancement entry!
Our very critical problem is that, when we do edits in ArcGIS Pro and also execute (custom) GP tools on the same workspace, the edits made by the GP-Tools do not show up in ArcGIS Pro! This means the workspaces are noch synced between the edit session in ArcGIS Pro and the edit session established during GP tool execution.
Also with ArcSDE based data sources the edits done by the GP tool sometimes cannot be saved, if in parallel edits on the same version were made in ArcGIS Pro. Stop editing then fails with the error "The version has been redefined to reference a new database state.". I commented on that in https://pro.arcgis.com/en/pro-app/latest/tool-reference/tool-errors-and-warnings/160001-170000/tool-...
But now my question regarding this enhancement for AGP 3.4 you mention:
FYI, this feature has also been added to custom script and model tools.
Does this mean the undo / redo toggle button should now be visible for all custom tools in ArcGIS Pro 3.4, too?
I just tried it out in ArcGIS Pro 3.4, but unfortunately the toggle button still does not show there and the edit sessions of ArcGIS Pro and GP tools are still not synced.
Thanks and regards,
Christoph
Hello @ChristophKoschmieder , to answer some of your questions and concerns....
Does this mean the undo / redo toggle button should now be visible for all custom tools in ArcGIS Pro 3.4, too?
No, the undo toggle is for tools that are in the new .atbx file format. So, you may need to update your tool, this can be as easy as a copy-paste from a tbx to an atbx. Then within the General tab of the Tool Properties dialog box, you can add the enable undo toggle in the Attribute options.
In order to use enable undo, the script's execution code must be set up correctly:
Also some things to keep in mind:
Also with ArcSDE based data sources the edits done by the GP tool sometimes cannot be saved...
If you are seeing something unusual about enterprise geodatabase systems, please submit as a bug to technical support.
thanks a lot for your quick reply! I still have to understand and evaluate it in total, though, but one new question already came up regarding the following statement:
The tool must have a derived output parameter set with dependency on the input parameter, to indicate that the input is updated by the tool code and should be locked during execution and refreshed when done. This is necessary to prevent someone from trying to edit a dataset in Pro at the same time that the dataset is being edited in the script, which would result in an error/lock
Is this also limited to the new toolbox format (*.atbx) or should especially the "refresh when done" part work with python toolboxes as well?!
Currently I tried to add a derived parameter corresponding to the input parameter (the layer which table is updated by the tool) as you suggested, but unfortunately the layer is not being refreshed afterwards. (I tried it AGP 3.2, 3.3 and 3.4)
Remark (if of importance):
The updated layer contains a join and is based on an ArcSDE data source. The unique value renderer of the layer is based on a field of the target table.
Is this also limited to the new toolbox format (*.atbx) or should especially the "refresh when done" part work with python toolboxes as well?!
The new attribute options can only be set for .atbx toolbox tools. When I said the tool will "refresh" when it finishes running, I meant the attributes table and layer will refresh to reflect the changes the tool made.
Currently I tried to add a derived parameter corresponding to the input parameter (the layer which table is updated by the tool) as you suggested, but unfortunately the layer is not being refreshed afterwards. (I tried it AGP 3.2, 3.3 and 3.4)
You will either need to set the dependency in the tool properties Parameters, or use arcpy.SetParameter in the Execution script for the refresh to happen.
The updated layer contains a join and is based on an ArcSDE data source. The unique value renderer of the layer is based on a field of the target table.
Arcpy.da cursors do not work with input layers that have a join. Please refer to this documentation for more information. https://pro.arcgis.com/en/pro-app/latest/arcpy/data-access/updatecursor-class.htm#D_GUID-6571F297-8B...
Hi Everyone, If you want to learn more about enable undo for custom tools, I posted a blog earlier this week about some new features added in the latest releases for creating custom tools.
Please check out the Build Better Custom Geoprocessing tools (now with Enable Undo) in ArcGIS Pro! blog.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.