Latest Contributions by Wolf

It looks like there's a gap in the ArcGIS Pro API.  Normally you would call FrameworkApplication.ContextMenuDataContext to get the 'underlying' (to your right click) tool.  The problem is that the returned object is an ArcGIS Pro internal class and hence you can't use that class in your add-in.   There is a workaround using reflection that allows you to access the underlying 'tool' context.  However, be advised that this solution is outside the Pro API framework and hence subject to change.  We will submit a new requirement to the Geoprocessing team for consideration.   In order to get the current (right clicked) tool insert this code inside your 'OnClick' button function: protected override void OnClick() { try { var toolInfo = FrameworkApplication.ContextMenuDataContext; //as ArcGIS.Desktop.GeoProcessing.ToolInfoViewModel; // internal class ToolInfo: // public string Name // public string Description // public string ToolType // public bool IsValid // public string ToolBoxName // public string FullPath // public bool IsSystem // public string toolName string name = (string)toolInfo.GetType().GetProperty("Name").GetValue(toolInfo, null); string description = (string)toolInfo.GetType().GetProperty("Description").GetValue(toolInfo, null); string toolType = (string)toolInfo.GetType().GetProperty("ToolType").GetValue(toolInfo, null); string toolBoxName = (string)toolInfo.GetType().GetProperty("ToolBoxName").GetValue(toolInfo, null); string fullPath = (string)toolInfo.GetType().GetProperty("FullPath").GetValue(toolInfo, null); string toolName = (string)toolInfo.GetType().GetProperty("toolName").GetValue(toolInfo, null); bool isValid = (bool)toolInfo.GetType().GetProperty("IsValid").GetValue(toolInfo, null); bool isSystem = (bool)toolInfo.GetType().GetProperty("IsSystem").GetValue(toolInfo, null); string nl = Environment.NewLine; MessageBox.Show($@"Type of toolInfo: {toolInfo.GetType().ToString()}{nl}" + $@"name: {name}{nl}" + $@"description: {description}{nl}" + $@"toolType: {toolType}{nl}" + $@"toolBoxName: {toolBoxName}{nl}" + $@"fullPath: {fullPath}{nl}" + $@"toolName: {toolName}{nl}" + $@"isValid: {isValid}{nl}" + $@"isSystem: {isSystem}{nl}"); } catch (Exception ex) { MessageBox.Show(ex.Message); } } Sample output:   ... View more

I tried the sample snippet you referred to above and did notice an issue with the sample.  If you look at the "private void GetMapMembers(MapView mapView)" method, you can see that this method is always running on the thread it is called from.  Unfortunately, when the 'query definition' custom dockpane is open and a new featureclass or table is added to the current map, this method is called from a background thread which in turn is throwing an exception.   So to correct this i made the following changes to the sample: private void GetMapMembers(MapView mapView) { RunOnUiThread(() => { MapMembers.Clear(); if (mapView != null) { var tocLayers = mapView.Map.GetLayersAsFlattenedList().OfType<BasicFeatureLayer>().ToList(); var tocTables = mapView.Map.StandaloneTables.ToList(); if (tocLayers.Count > 0 || tocTables.Count > 0) { tocLayers.ForEach(x => _mapMembers.Add(x)); tocTables.ForEach(t => _mapMembers.Add(t)); var selectedMapMember = GetSelectedMapMemberInTOC(); if (selectedMapMember != null) //mapmember has been selected SelectedMapMember = selectedMapMember; //Show that map member's filters else SelectedMapMember = MapMembers[0]; //default. Nothing selected in TOC } //If no feature layers, show empty dockpanes(DockpaneVisibility) DockpaneVisibility = MapMembers.Count == 0 ? Visibility.Hidden : Visibility.Visible; } }); } And here are the supporting functions: #region Threading Utilities /// <summary> /// utility function to enable an action to run on the UI thread (if not already) /// </summary> /// <param name="action">the action to execute</param> /// <returns></returns> internal static Task RunOnUiThread(Action action) { if (OnUIThread) { action(); return Task.FromResult(0); } else return Task.Factory.StartNew(action, System.Threading.CancellationToken.None, TaskCreationOptions.None, QueuedTask.UIScheduler); } /// <summary> /// determines if the application is currently on the UI thread /// </summary> private static bool OnUIThread { get { if (FrameworkApplication.TestMode) return QueuedTask.OnWorker; else return System.Windows.Application.Current.Dispatcher.CheckAccess(); } } #endregion I will try drag and drop and some other test cases next, but in general I would recommend embedding all custom code in try {} catch {} to prevent crashes that are caused by uncaught exceptions with no error message.    ... View more

@StephenDavis1  Pro SDK documentation only mentions that ‘Add-ins’ are forward compatible between minor versions.  If you write a CoreHost standalone app for ArcGIS Pro 3.1 you can achieve forward compatibility as well, but there are a few caveats: Your CoreHost app is in essence a .NET console app with references to the following ArcGIS Pro assemblies: ArcGIS.Core and ArcGIS.CoreHost.  You have to make sure that the “Copy Local” attribute for these references is set to “NO”.   You also have to add code in your CoreHost app to resolve the path to these assemblies (they are located in the ArcGIS Pro installation bin folder).  This ensures that your CoreHost application is actually running the assemblies that are installed with ArcGIS Pro and not a potentially outdated (or mismatched versions) assembly copy included with your CoreHost app. Also, your CoreHost app cannot be a ‘self-contained’ .NET application, instead it has to have a ‘Target Framework’.  In order to implement this, you have to edit your .CSPROJ file and add the following setting under the property group: <SelfContained>false</SelfContained> When a console app is ‘self-contained’, the runtime for the target .NET version is included with the binary output when the console application is built.   However, this feature is not desirable because this would mean that your .NET runtime version is static. If you follow the steps above your CoreHost standalone app can be forward compatible, but the problem is that the app will only allow the target .NET version to be loaded.  So, in our case since you built the app using the Pro SDK 3.1 this means that the CoreHost app is permanently linked to .NET 6.0 (or any minor release of .NET 6.0).  I added a small sample project called ‘CoreHostTest31Build’ to this post so you can see an implementation of a ‘forward compatible’ capable CoreHost app. If you look at the .json files included with the corehost app you will notice that they are ‘bound’ to a specific .NET target of .NET 6.0, which means that the CoreHost app will not work under ArcGIS Pro 3.3 since Pro 3.3 requires .NET 8.0.  You will get this error: > CoreHostTest31Build C:\Data\FeatureTest\FeatureTest.gdb Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. You can see that the CoreHost app is trying to load .NET 8.0 because ArcGIS Pro 3.3 requires .NET 8.0.  However, the CoreHost app is bound to .NET 6.0 and hence the loading of .NET 8.0 fails. This problem can be fixed by updating the .NET target framework version is the CoreHost’s CoreHost.deps.json file and CoreHost.runtimeconfig.json to .NET 8.0.  You can do this manually before you call your CoreHost app from the command line, or you can use the RunCoreHostApp command line utility to run your CoreHost app under ArcGIS Pro 3.1, 3.2, or 3.3.  This app will make the .json file changes for you: RunCoreHostApp CoreHostTest31Build C:\Data\FeatureTest\FeatureTest.gdb I included the RunCoreHostApp solution.  After you build the solution simply copy the executable into your CoreHost executable folder, now you have ‘forward compatibility’. ... View more