Sta toe dat add-ins aangepaste dialoogvensters (of aangepaste parameterbedieningen) kunnen bieden voor geoprocessing-tools

JeffJenness

Samenvatting van het probleem

Het geoprocessing-framework is een van de grootste sterke punten van ArcGIS Pro, en externe ontwikkelaars worden terecht naar dit framework geleid: een tool die is gebouwd als een scripttool of Python toolbox krijgt geoprocessing-geschiedenis, omgevingsinstellingen, voortgangs- en berichtrapportage, batchmodus, ModelBuilder-composability, en arcpy scripting — een ecosysteem dat geen enkele aangepaste dialoog ooit zou kunnen nabouwen.

Maar dat ecosysteem wordt geleverd met precies één gebruikersinterface: het automatisch gegenereerde geoprocessing-paneel. Er is geen ondersteunde manier voor een tool van derden om een andere UI te presenteren terwijl het toch een echte geoprocessing-tool blijft. Voor eenvoudige tools is het gegenereerde paneel prima. Voor interactieve workflows met veel feedback is het echter zeer beperkend, en ontwikkelaars staan voor een onnodige keuze:

• Blijf een GP-tool en accepteer de beperkingen van het gegenereerde paneel (geen aangepaste widgets, geen live previews, beperkte lay-outcontrole en een lange lijst met validatiegedragsquirks), of
• Bouw een aangepast dockpaneel/venster met precies de juiste UI — en verlies volledig de geoprocessing-geschiedenis, omgevingen, ModelBuilder, batch en scripting.

De eigen toonaangevende interactieve workflows van Esri tonen het probleem aan: de Suitability Modeler, de image Classification Wizard en Georeferencing zijn allemaal aangepaste panelen, geen gegenereerde geoprocessing-dialoogvensters. Wanneer rijke interactie belangrijk is, omzeilt Esri het GP-paneel. Ontwikkelaars van derden hebben geen ondersteunde manier om hetzelfde te doen zonder het geoprocessing-framework te verlaten.

Gevraagde verbetering

Ontkoppel de tool-UI van de tool. Twee niveaus, waarvan elk een grote stap zou zijn:

Niveau 1 — aangepaste tool-dialoogvensters (de volledige aanvraag). Laat een add-in een WPF-dialoog/paneel registreren als de Pro UI voor een specifieke geoprocessing-tool (scripttool, .pyt, of .atbx). De tool blijft in alle andere opzichten een volwaardige GP-tool:

• De aangepaste dialoog verzamelt en valideert parameters en geeft vervolgens een standaard parameterarray door aan de normale GP-uitvoeringspijplijn — zodat de uitvoering wordt vastgelegd in de geoprocessing-geschiedenis, omgevingsinstellingen worden gerespecteerd, voortgang/berichten worden gerapporteerd en metadata precies worden gestempeld zoals nu.
• Contexten die het aangepaste dialoogvenster niet kunnen hosten — ModelBuilder, batchmodus, geplande uitvoeringen, serverpublicatie, arcpy — vallen automatisch terug op het automatisch gegenereerde paneel en bestaande parameterobjecten. Niets gaat kapot.
• Als er geen aangepast dialoogvenster is geregistreerd, is het gedrag precies zoals vandaag (volledig achterwaarts compatibel).

Niveau 2 — aangepaste parameterbedieningen (een kleinere maar nog steeds transformerende aanvraag). Laat een ontwikkelaar een aangepast WPF-besturingselement registreren voor een individuele parameter (of een aangepast parametertype), gehost binnen het gegenereerde paneel. Zelfs dit zou het grootste deel van de pijn wegnemen: een waardetabel kan veranderen in een echte raster met live feedback; een remap-parameter kan een histogram van de invoerraster tonen; een drempelwaarde kan laten zien welke cellen worden geselecteerd.

Waarom het belangrijk is

Aangepaste Python-toolkasten zijn een volwaardige uitbreidingsmogelijkheid voor ArcGIS Pro, en organisaties en derden bouwen serieuze analysesuites van commerciële kwaliteit erop. De kwaliteit van wat de gebruiker ziet wordt niet bepaald door de inspanning van de ontwikkelaar maar door het gegenereerde paneel. Ontwikkelaars die geven om gebruikerservaring worden gedwongen het geoprocessing-framework te verlaten — waarbij ze herkomst, reproduceerbaarheid en scriptbaarheid verliezen, juist die dingen die Pro-tools betrouwbaar maken. Een ondersteund uitbreidingspunt voor UI zou die afweging beëindigen, de kwaliteitslat voor het hele ecosysteem van derden verhogen en niets kosten in achterwaartse compatibiliteit.

JeffJenness

Concrete limitations met while building one real toolbox — all encountered (and independently reproducible) while porting a large wildlife-analysis toolset to a Python toolbox in ArcGIS Pro 3.7. Each is livable alone; together they show why a supported custom-UI path is needed. Items marked ◆ are also candidates for individual bug reports via My Esri support.

1. ◆ Value-table cell marshaling is inconsistent and undocumented. During dialog validation, a GPValueTable cell holding a map layer or table arrives as the bare display-name text when dragged in, but as a wrapper object (MappingLayerObject / MappingTableObject) whose str() is only a repr (<MappingTableObject object at 0x…>) when picked from the cell's dropdown. Validation code must defensively handle both; naive str() use produces false "does not exist" errors.
2. ◆ No supported project access during validation. arcpy.mp.ArcGISProject("CURRENT") is unreliable/unsupported in updateParameters, so a tool cannot resolve a layer name to its data source to drive smart defaults (e.g., suggesting a companion table that sits beside the input raster in a geodatabase).
3. No opt-out of framework output auto-naming. When the first input changes, Pro fills an empty required output with <first input>_<tool name>. For multi-input tools the first input is often not what the output is about (e.g., one habitat factor out of six), so the suggestion is reliably wrong — and the tool cannot suppress it.
4. No way to set the Browse dialog's starting location per parameter, even when the tool knows exactly where the relevant files live.
5. "Suggest once, let the user clear it" requires an undocumented idiom. .altered does not distinguish a user-cleared value, so usable auto-defaults hinge on the undocumented hasBeenValidated behavior.
6. ◆ A disabled output parameter that still holds a value gets its dataset deleted on Run (overwrite-output pre-delete runs before execute()), even though the parameter is disabled — a data-loss trap for mode-toggle dialogs.
7. No show/hide for parameters, and limited layout control. Category groups always render below all uncategorized parameters, and categories default to collapsed; a parameter cannot be hidden when a mode makes it irrelevant.
8. Empty value-table rows added with "Add another" are pruned whenever the pane refreshes or loses focus, so a user cannot click Browse in a freshly added row — and dragging a layer onto the control does not append a row either. The cell dropdowns are the only reliable way to add a row.
9. Raster inputs can surface as CIMPATH=…/….json URIs in .valueAsText that arcpy.Describe/CopyRaster reject, requiring resolution through the value object instead.
10. No custom widgets of any kind. No histogram or preview of an input raster, no live chart, no color swatches, no rich text. In our suite, an interactive remap-table builder had to be written as a fully custom add-in window — losing geoprocessing history for that step — because the pane simply cannot host it.
11. The multivalue value-list control always offers "Select All," even when selecting everything is semantically wrong — a geographic-transformation list where exactly one entry per datum pair is meaningful, say. No toolbox property suppresses or renames it.
12. ◆ Geometry filters cannot be applied to mixed raster/feature parameters. Parameter.filter.list = ["Polygon"] works on a feature-only composite (["GPFeatureLayer", "DEFeatureClass"]), but raises NameError: The attribute 'list' is not supported on this instance of Filter the moment raster types join the composite (["GPFeatureLayer", "GPRasterLayer", "DEFeatureClass", "DERasterDataset"] — the natural datatype for a tool that combines polygon layers AND rasters in one multivalue list). Consequence: a polyline or point layer cannot be refused at drag-in or browse time; the only available protection is an error posted from updateMessages, which does block Run but only after the wrong layer already sits in the list — and which the developer must remember to re-post on every validation cycle, since messages are cleared each pass.

Why existing workarounds don't substitute: a custom window that calls processing code directly orphans the run from history, environments, and scripting; a custom window that wraps the GP tool via ExecuteToolAsync preserves those but forces the developer to build and maintain two UIs per tool, and ModelBuilder users still see only the generated pane. Both paths exist precisely because the supported one is missing.

I'm happy to file the ◆ items individually via My Esri support and cite this idea as the systemic fix, if that's useful — let me know.