Select to view content in your preferred language

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

446
7
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.

1 Solution

Accepted Solutions
NarelleChedzey
Esri Contributor

Hi Jeff, 

Unfortunately we do not have this capability in the Editing API at this point  We do have an issue in our backlog for this work and will be addressing it for the 3.6 release. 

Narelle

 

View solution in original post

7 Replies
NarelleChedzey
Esri Contributor

Hi Jeff, 

Unfortunately we do not have this capability in the Editing API at this point  We do have an issue in our backlog for this work and will be addressing it for the 3.6 release. 

Narelle

 

Jeff-Reinhart
Frequent Contributor

Thanks, @NarelleChedzey, good to have that confirmed.

0 Kudos
JeffMatson
Frequent Contributor

We have a similar requirement to constrain editing to a named version.  Here's a sample that listens to the MapMemberPropertiesChanged event, specifically for when a user interacts with the List By Editing tab of the Contents pane.  (This isn't shown in the sample below, but FixEditability() should also be called as soon as the Map is ready when the project opens.) 

Hopefully the 3.6 release makes this workaround unnecessary.

 private static bool m_bEditabilityHandled = false;
 private Module1()
 {
     MapMemberPropertiesChangedEvent.Subscribe(OnMapMemberPropertiesChanged);
 }
 private static void OnMapMemberPropertiesChanged(MapMemberPropertiesChangedEventArgs args)
 {
     if (m_bEditabilityHandled == false)
     {
         foreach (var v in args.EventHints)
         {
             Debug.WriteLine(v.ToString());
             try
             {
                 if (v.ToString().ToUpper() == "EDITABILITY")
                 {
                     FixEditability();
                 }
             }
             catch (Exception ex) { }
         }
     }
 }

 private static void FixEditability()
 {
     m_bEditabilityHandled = true;
     try
     {
         var activeMap = MapView.Active.Map;
         var lstLayers = activeMap.GetLayersAsFlattenedList().OfType<FeatureLayer>();
         foreach (var l in lstLayers)
         {
             if (l != null)
             {
                 try
                 {
                     Table t = l.GetTable();
                     Geodatabase gdb = t.GetDatastore() as Geodatabase;
                     if (gdb.GetGeodatabaseType() == GeodatabaseType.RemoteDatabase)
                     {
                         var gdbConnProps = (DatabaseConnectionProperties)gdb.GetConnector();
                         if (gdbConnProps != null)
                         {
                             string v = gdbConnProps.Version.ToString();
                             if (string.IsNullOrEmpty(v) || v.ToUpper() == "SDE.DEFAULT")
                             {
                                 BasicFeatureLayer bfl = l as BasicFeatureLayer;
                                 bfl.SetEditable(false);
                             }
                         }
                     }
                 }
                 catch (Exception ex) { }
             }
         }
     }
     catch (Exception ex) { }
     finally { m_bEditabilityHandled = false; }
 }

 

Jeff-Reinhart
Frequent Contributor

Thanks for this. It does prevent the user from being able to edit the layers that we set IsEditable to false.

I was hoping that setting BasicFeatureLayer.SetEditable(false) would mean that the layer would not be included in the Choose Workspace dialog. That is not the case. Layers with IsEditable set to false are still included and the user can still choose to edit that source. It will cost us some time and effort to explain this to our users. Looking forward to a fix.

0 Kudos
Jeff-Reinhart
Frequent Contributor

Setting our non-versioned datasets as IsEditable false brings in another problem. If the user picks the non-versioned workspace in the Choose Workspace dialog by accident, stops editing, and then starts editing on the versioned workspace, edits will fail on the versioned data. The project has to be closed and opened again to be able to have a functional edit session on the versioned data. I have not been able to pin down why yet. The generic error message is no help. Any ideas would be appreciated.

0 Kudos
Scott_Harris
Esri Regular Contributor

@Jeff-Reinhart 

  1. What is the error that you are getting?
  2. Where is the data?
    • Is it in the same geodatabase?
    • Is it in the same feature dataset?
0 Kudos
Jeff-Reinhart
Frequent Contributor

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

0 Kudos