Select to view content in your preferred language

Can we override the Choose Workspace dialog and set the workspace programmatically?

1130
15
Jump to solution
03-20-2025 12:58 PM
Jeff-Reinhart
Frequent Contributor

Working on a custom ArcGIS Pro Configuration / Add-in. We need to constrain editing to only versioned datasets in a particular geodatabase. Users also need an edit session. They need to be able to stop editing and not save edits. Short transactions would not work well for our user base. In pursuit of this, we have changed Options | Editing | Session | “Enable and disable editing from the Edit tab” to True and have set “single workspace edit session” via

ApplicationOptions.EditingOptions.EnableEditingFromEditTab = true;

When the user starts editing, they are prompted with the Choose Workspace dialog (even if there is only one workspace to choose from). If we know the workspace the user will be editing, the user should not need to go through the extra step of picking the workspace. Is there a way to override the Choose Workspace dialog and set the workspace for the user via the code? I have not found a way to specify a default workspace in the UI and searching the docs for an override has not turned up an answer.

15 Replies
JeffMatson
Frequent Contributor

Thanks for suggesting database role permissions @Jeff-Reinhart .  I'm not sure my organization will allow for that, but I'm going to use your experience for persuasion purposes.   And yes, looking forward to this being fixed in a future release of ArcGIS Pro as well.

0 Kudos
Jeff-Reinhart
Frequent Contributor

@JeffMatson, I spoke too soon. If editing is started on the Enterprise Geodatabase Data (nonversioned), the expected error (this layer’s workspace is read only) fires for edits on datasets that are edited via:

EditOperation.Create() or EditOperation.Modify()

However, the expected error does NOT fire if an edit is made using

EditOperation.Callback()

That would be used on tables in the geodatabase that are not included in the Pro project. So if everything you are editing is included in the Pro project, meaning you don’t have to use EditOperation.Callback(), creating a database role and setting rights per dataset may work for you.

I have not tested EditOperation.Delete(), but I’d assume that would follow suit with EditOperation.Create() and EditOperation.Modify().

0 Kudos
Jeff-Reinhart
Frequent Contributor

I have isolated this better. The following steps will generate the “Edit operation failed. This layer’s workspace is read only.” unexpectedly on the versioned SDE:

  • Start editing with Project.Current.SetIsEditingEnabledAsync(true);
  • User is prompted with the Choose Workspace dialog. User chooses Enterprise Geodatabase Data (nonversioned).
  • Edit a versioned table in the same SDE via EditOperation.Create(). Edit operation fails with “workspace is read only” error (this is expected).
  • Stop editing with SetIsEditingEnabledAsync(false);
  • Start editing with Project.Current.SetIsEditingEnabledAsync(true);
  • User is prompted with the Choose Workspace dialog. User chooses Enterprise Geodatabase Data (versioned).
  • Edit a versioned table in the same SDE via EditOperation.Create(). Edit operation fails with “workspace is read only” error (this is NOT expected).

Cannot shake the error on editing the versioned data loose without restarting Pro.

NarelleChedzey
Esri Contributor

Hi Jeff, 

I wanted to follow up on this thread. 

We were able to duplicate your issue with the SetIsEditingEnabledAsync API method when switching between editing versioned and non versioned workspaces. Thanks for your very clear repro case.   This bug has been fixed and will be in Pro 3.6. 

In addition the work has been completed to add additional API methods to specify single workspace edit sessions.  This includes the additional setting on the EditingOptions class along with extension methods on the Project class to specify the workspace to edit.   You'll be able to specify the workspace to edit in a number of different ways.  Using a ArcGIS.Core.Data.Datastore datastore object, using a MapMember, or using a new class - a DatastoreConfiguration  - that will allow you to specify the datastore along with a versioned/non-versioned state for the cases where the datastore has a mixture of versioned and non-versioned data. 

Thanks

Narelle

 

Jeff-Reinhart
Frequent Contributor

Thanks! Looking forward to it!

0 Kudos
Jeff-Reinhart
Frequent Contributor

Thanks for the snippet, @JeffMatson. I might be able to use that!

0 Kudos