Povolit doplňkům poskytovat vlastní dialogy (nebo vlastní ovládací prvky parametrů) pro geoprocesní nástroje

JeffJenness

Shrnutí problému

Geoprocesní rámec je jednou z největších předností ArcGIS Pro a vývojáři třetích stran jsou správně k němu vedeni: nástroj vytvořený jako skriptový nástroj nebo Python toolbox získává historii geoprocesu, nastavení prostředí, hlášení průběhu a zpráv, režim dávkového zpracování, složitelnost v ModelBuilderu a arcpy skriptování — ekosystém, který žádný vlastní dialog nikdy nemůže znovu vytvořit.

Ale tento ekosystém je dodáván s přesně jedním uživatelským rozhraním: automaticky generovaným panelem geoprocesu. Neexistuje žádný podporovaný způsob, jak může nástroj třetí strany zobrazit jiné UI a přitom zůstat skutečným geoprocesním nástrojem. Pro jednoduché nástroje je generovaný panel dostačující. Pro interaktivní workflow bohaté na zpětnou vazbu je to však velmi omezující a vývojáři čelí zbytečné volbě:

• Zůstat GP nástrojem a přijmout omezení generovaného panelu (žádné vlastní widgety, žádné živé náhledy, omezená kontrola rozvržení a dlouhý seznam zvláštností validačního chování), nebo
• Vytvořit vlastní dockpane/okno s přesně vhodným UI — a úplně přijít o historii geoprocesu, prostředí, ModelBuilder, dávkový režim a skriptování.

Vlajkové interaktivní workflow Esri ukazují problém: Suitability Modeler, image Classification Wizard a Georeferencing jsou všechny vlastní panely, ne generované geoprocesní dialogy. Když záleží na bohaté interakci, Esri obchází GP panel. Vývojáři třetích stran nemají podporovaný způsob, jak udělat totéž bez opuštění geoprocesního rámce.

Požadované vylepšení

Oddělit UI nástroje od samotného nástroje. Dva stupně, z nichž každý by byl významným krokem:

Stupeň 1 — vlastní dialogy nástrojů (plná žádost). Nechat doplněk zaregistrovat WPF dialog/panel jako Pro UI pro konkrétní geoprocesní nástroj (skriptový nástroj, .pyt, nebo .atbx). Nástroj zůstává ve všech ostatních ohledech plnohodnotným GP nástrojem:

• Vlastní dialog shromažďuje a ověřuje parametry a pak předává standardní pole parametrů do běžného GP spouštěcího procesu — takže běh je zaznamenán v historii geoprocesu, respektuje nastavení prostředí, hlásí průběh/zprávy a přidává metadata přesně jako dnes.
• Kontexty, které nemohou hostit vlastní dialog — ModelBuilder, dávkový režim, plánované spuštění, publikování na serveru, arcpy — automaticky přepnou na automaticky generovaný panel a existující objekty parametrů. Nic se nezhroutí.
• Pokud není registrován žádný vlastní dialog, chování je přesně jako dnes (plná zpětná kompatibilita).

Stupeň 2 — vlastní ovládací prvky parametrů (menší ale stále transformační požadavek). Nechat vývojáře zaregistrovat vlastní WPF ovládací prvek pro jednotlivý parametr (nebo vlastní datový typ parametru), umístěný uvnitř generovaného panelu. I to by odstranilo většinu bolesti: tabulka hodnot by se mohla stát skutečnou mřížkou s živou zpětnou vazbou; remap parametr by mohl zobrazit histogram vstupního rastru; práh by mohl ukázat vybrané buňky.

Proč je to důležité

Vlastní Python toolboxy jsou plnohodnotnou cestou rozšiřitelnosti pro ArcGIS Pro a organizace i třetí strany na nich staví vážné komerční analytické sady. Kvalita toho, co uživatel vidí, není omezena úsilím vývojáře, ale generovaným panelem. Vývojáři dbající na uživatelskou zkušenost jsou tlačeni opustit geoprocesní rámec — přicházejí tak o původ dat, reprodukovatelnost a skriptovatelnost, tedy právě ty věci, které dělají nástroje Pro důvěryhodnými. Podporovaný bod rozšiřitelnosti UI by tento kompromis ukončil, zvýšil kvalitu celého ekosystému třetích stran a nezpůsobil žádné problémy se zpětnou kompatibilitou.

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.