Can I prevent activation of Editing pane when I execute a IPlugInWrapper command?

[ViktorSafar]

I have a custom dockpane where the VM activates vertex editing of the current feature.

var editCommand = FrameworkApplication.GetPlugInWrapper("esri_editing_editVerticesCurrentFeature") as ICommand;
if (editCommand != null && editCommand.CanExecute(null))
{
	editCommand.Execute(null);
}

Pro activates the Modify Features pane and switches the focus to it. Can I somehow stay on my custom dockpane?editCommand.Execute

I have tried to activate my custom dockpane this.Activate() after the editCommand.Execute() method but it appears whatever happens behind the editCommand.Execute is async so my Activate() has no effect.

Is there an event that I can hook into upon the Modify Features pane activation? Or just prevent the activation altogether?

It is possible I am overengineering this. My goal is to let the user edit the vertices of the current feature and then return back to my custom pane.

[GKmieliauskas]

Hi,

You can dock your docpane to TOC side

[John_Jones]

---

It is possible I am overengineering this. My goal is to let the user edit the vertices of the current feature and then return back to my custom pane.

---

You could try instead suing FrameworkApplication.ExecuteCommand()..

https://pro.arcgis.com/en/pro-app/latest/sdk/api-reference/topic10149.html

The API is a little strange as it doesn't start executing the command instead immediately, instead it gives you back a handle to a Func<Task> that when called will start executing the command and then it will hand back a Task. In some instances this Task will be already complete, but I believe at least in this case the Task will not complete until after the associated tool has completed activation (including deactivating the prior tool) and that should include giving focus to the Dock pane.  

For ArcGIS Tasks we have a mechanism for redirecting the tool's UI to be hosted in the Tasks' dock pane.  I may (in a future release) be able to come up with a similar mechanism so that your custom pane can be registered to either (at your direction) a) host this UI or b) just prevent the UI from hosting in the "Modify Features" dock pane.  I hadn't heard of this exact requirement before, but it does seem useful, we just need to develop a flexible mechanism for controlling behavior of what is nominally only very opaquely exposed to the API (a DAML plugin implementing the tool.)  Of course we could expose an alternate Command (with a unique DAML id) that did what you want, skipping either the pane focusing or the presentation of the tool's UI in the "Modify Features" dock pane entirely, but that isn't very flexible and would quickly bloat all the commands with variants. 

Hopefully the above will allow you to make a work around to re-focus your view reasonably, but I believe we can do better in the future (can't think of any other easy way to work around this that would be reliable).

[ViktorSafar]

Thanks John. FrameworkApplication.ExecuteCommand("esri_editing_editVerticesCurrentFeature") returns null. 

[John_Jones]

Thanks sorry about that, I'll try to get that addressed in the next version (I see why that one is not set.)

[John_Jones · Accepted solution]

As a work around, the very similar command "esri_editing_EditVerticesModifyFeature" may be a suitable substitute (if only that one feature is selected).

[ViktorSafar]

Thanks.

I abandoned my plan of staying on my custom pane and ended up with hooking into SketchCompletedEvent and activating my custom pane. This way the user is brought back to my custom pane when they finish the vertex editing. (note to future readers: you may also want to hook into SketchCanceledEvent)

(this code is in the VM that controls the custom pane, hence inherits the this.Activate() method)

ArcGIS.Desktop.Mapping.Events.SketchCompletedEvent.Subscribe(ags =>
{
	MapView.Active.Map.ClearSelection();
	Application.Current.Dispatcher.Invoke(() => this.Activate());
});

var editCommand = FrameworkApplication.GetPlugInWrapper("esri_editing_EditVerticesModifyFeature") as ICommand;
if (editCommand != null && editCommand.CanExecute(null))
{
	editCommand.Execute(null);
}