Select to view content in your preferred language

Why does Project.Current.SetIsEditingEnabledAsync(true) not refresh data in the same way the esri_editing_ToggleEditBtn does?

460
4
Jump to solution
04-21-2025 01:07 PM
Jeff-Reinhart
Frequent Contributor

Scenario:

SDE database. Feature class registered as versioned. Traditional versioning with DEFAULT version only. Version access public. ArcGIS Pro Options | Editing | “Enable and disable from the Edit tab” = True and “Single workspace edit session” selected.

Behavior using esri_editing_ToggleEditBtn:

Two separate ArcGIS Pro instances open. Start editing in instance 1 using the Ribbon | Edit tab | Edit button (esri_editing_ToggleEditBtn). Edit attribute in feature class. Save edits and stop editing. Start editing in instance 2 using the esri_editing_ToggleEditBtn. Attributes in same feature class in instance 2 refresh with edit made in instance 1.

Behavior using SetIsEditingEnabledAsync:

Same two separate ArcGIS Pro instances open. Start editing in instance 1 using the esri_editing_ToggleEditBtn. Edit attribute in feature class. Save edits and stop editing. Start editing in instance 2 using Project.Current.SetIsEditingEnabledAsync(true). Following pattern shown here: https://github.com/Esri/arcgis-pro-sdk/wiki/ProSnippets-Editing#enable-editing-1. Attributes in feature class in instance 2 DO NOT refresh to edit made in instance 1.

Attempts to refresh otherwise:

I have tried running the following in an awaited QueuedTask prior to running SetIsEditingEnabledAsync from another awaited QueuedTask:

var connectionString = new Uri("C:\\dir\\my_sde.sde");
using var gdb = new Geodatabase(new DatabaseConnectionFile(connectionString));
using var versionManager = gdb.GetVersionManager();
using var version = versionManager.GetCurrentVersion();
version.Refresh();

If an edit session was previously started via SetIsEditingEnabledAsync, then version.Refresh() throws error: ArcGIS.Core.Data.Exceptions.GeodatabaseEditingException: 'This operation is not allowed while editing.' This occurs even after having run Project.Current.SetIsEditingEnabledAsync(false);.

Questions:

Why does Project.Current.SetIsEditingEnabledAsync(true) not refresh attributes the same way the esri_editing_ToggleEditBtn does?

What is the best way to refresh attributes when starting an edit session via Project.Current.SetIsEditingEnabledAsync(true)?

0 Kudos
1 Solution

Accepted Solutions
Jeff-Reinhart
Frequent Contributor

I inadvertently found a workaround that allows me to continue using SetIsEditingEnabledAsync() and still get updates from other edit sessions that occurred during the current Pro session. Long story short, performing an edit using EditOperation.Create() and then saving that edit using Project.Current.SaveEditsAsync() results in all datasets refreshing with changes from other sessions.

Long story… I had another issue where the workaround for that lead to the realization. Pro 3.5 does not allow the workspace for the single workspace edit session to be programmatically set (looking forward to this in 3.6). Our database has versioned and non-versioned data. Users should only be able to edit the versioned data.

If the user picks the non-versioned workspace when starting editing, makes an edit via EditOperation.Create() (which throws a read-only error), stops editing, then starts editing on the versioned data, edits will fail with a read only error on the versioned data. So something is being sticky. To deal with that, after the user starts edits, I check if the versioned workspace is what is being edited and if not, I unfortunately have to kick the user out of the app and make them restart. Closing Pro and reopening is the only way I found to get it unstuck.

The SDK does not provide a direct way to check which workspace is being edited, so I needed a workaround. The workaround was to attempt an edit using EditOperation.Create() and if EditOperation.Execute() returns false, I warn the user and close Pro. I needed an excuse to make an edit, so I created a logging table that logs the system username and the time. Might as well log when users are starting edits – could be useful info later. I didn’t want the user to have to save that edit, so I saved programmatically using Project.Current.SaveEditsAsync().

Presto! I have a saved edit that inadvertently causes datasets to refresh with changes from other edit sessions!

View solution in original post

0 Kudos
4 Replies
Wolf
by Esri Regular Contributor
Esri Regular Contributor

I am looking at this issue, but in the meantime i think you can just use the button directly instead of setting the set enable editing API method:

// if not editing
if (!Project.Current.IsEditingEnabled)
{
  var res = MessageBox.Show("You must enable editing to use editing tools. Would you like to enable editing?",
                                                        "Enable Editing?", System.Windows.MessageBoxButton.YesNoCancel);
  if (res == System.Windows.MessageBoxResult.No ||
                res == System.Windows.MessageBoxResult.Cancel)
  {
    return;
  }
  // Project.Current.SetIsEditingEnabledAsync(true);
  // use the esri_editing_ToggleEditingBtn instead for .SetIsEditingEnabledAsync
  var damlId = "esri_editing_ToggleEditingBtn";
  IPlugInWrapper wrapper = FrameworkApplication.GetPlugInWrapper(damlId);
  var command = wrapper as ICommand;
  if ((command != null) && command.CanExecute(null))
    command.Execute(null);
}
0 Kudos
Jeff-Reinhart
Frequent Contributor

Thank you, that approach does solve the initial issue. Unfortunately, it creates another issue in my application. I do need the process to enable editing to complete prior to running a few other tasks, so changing from SetIsEditingEnabledAsync() is causing issues. Is there a way I can run your snippet and await a completed task? I looked at setting up ICommand to run as an async task, but that is looking pretty complicated.

0 Kudos
Jeff-Reinhart
Frequent Contributor

Thanks for the reply. I am aiming to look into this workaround soon.

0 Kudos
Jeff-Reinhart
Frequent Contributor

I inadvertently found a workaround that allows me to continue using SetIsEditingEnabledAsync() and still get updates from other edit sessions that occurred during the current Pro session. Long story short, performing an edit using EditOperation.Create() and then saving that edit using Project.Current.SaveEditsAsync() results in all datasets refreshing with changes from other sessions.

Long story… I had another issue where the workaround for that lead to the realization. Pro 3.5 does not allow the workspace for the single workspace edit session to be programmatically set (looking forward to this in 3.6). Our database has versioned and non-versioned data. Users should only be able to edit the versioned data.

If the user picks the non-versioned workspace when starting editing, makes an edit via EditOperation.Create() (which throws a read-only error), stops editing, then starts editing on the versioned data, edits will fail with a read only error on the versioned data. So something is being sticky. To deal with that, after the user starts edits, I check if the versioned workspace is what is being edited and if not, I unfortunately have to kick the user out of the app and make them restart. Closing Pro and reopening is the only way I found to get it unstuck.

The SDK does not provide a direct way to check which workspace is being edited, so I needed a workaround. The workaround was to attempt an edit using EditOperation.Create() and if EditOperation.Execute() returns false, I warn the user and close Pro. I needed an excuse to make an edit, so I created a logging table that logs the system username and the time. Might as well log when users are starting edits – could be useful info later. I didn’t want the user to have to save that edit, so I saved programmatically using Project.Current.SaveEditsAsync().

Presto! I have a saved edit that inadvertently causes datasets to refresh with changes from other edit sessions!

0 Kudos