Add-ins erlauben, benutzerdefinierte Dialoge (oder benutzerdefinierte Parametersteuerungen) für Geoverarbeitungswerkzeuge bereitzustellen

JeffJenness

Zusammenfassung des Problems

Das Geoverarbeitungs-Framework ist eine der größten Stärken von ArcGIS Pro, und Drittentwickler werden zu Recht darauf hingewiesen: Ein Werkzeug, das als Skriptwerkzeug oder Python-Toolbox erstellt wurde, erhält Geoverarbeitungshistorie, Umgebungs-Einstellungen, Fortschritts- und Nachrichtenberichte, Batch-Modus, ModelBuilder-Komponierbarkeit und arcpy-Skripting – ein Ökosystem, das kein benutzerdefinierter Dialog jemals nachbilden könnte.

Dieses Ökosystem wird jedoch mit genau einer Benutzeroberfläche geliefert: dem automatisch generierten Geoverarbeitungsfenster. Es gibt keinen unterstützten Weg für ein Drittanbieter-Werkzeug, eine andere UI zu präsentieren und dabei ein echtes Geoverarbeitungswerkzeug zu bleiben. Für einfache Werkzeuge ist das generierte Fenster ausreichend. Für interaktive, feedbackreiche Arbeitsabläufe ist es jedoch stark einschränkend, und Entwickler stehen vor einem unnötigen Entweder-Oder:

• Bleibe ein GP-Werkzeug und akzeptiere die Grenzen des generierten Fensters (keine benutzerdefinierten Widgets, keine Live-Vorschauen, eingeschränkte Layoutkontrolle und eine lange Liste von Validierungsverhalten-Anomalien), oder
• Erstelle ein benutzerdefiniertes Dockpane/Fenster mit genau der richtigen UI – und verliere dabei vollständig Geoverarbeitungshistorie, Umgebungen, ModelBuilder, Batch und Skripting.

Esris eigene führende interaktive Arbeitsabläufe zeigen das Problem: der Suitability Modeler, der Image Classification Wizard und Georeferenzierung sind alle benutzerdefinierte Fenster, nicht automatisch generierte Geoverarbeitungsdialoge. Wenn reichhaltige Interaktion wichtig ist, umgeht Esri das GP-Fenster. Drittentwickler haben keinen unterstützten Weg, dasselbe ohne Aufgabe des Geoverarbeitungs-Frameworks zu tun.

Angeforderte Verbesserung

Entkopplung der Werkzeug-UI vom Werkzeug. Zwei Stufen, von denen jede einen großen Schritt darstellen würde:

Stufe 1 – benutzerdefinierte Werkzeugdialoge (die vollständige Anforderung). Ermöglichen Sie einem Add-in, einen WPF-Dialog/-Bereich als Pro-Benutzeroberfläche für ein bestimmtes Geoverarbeitungswerkzeug (Skriptwerkzeug, .pyt, oder .atbx) zu registrieren. Das Werkzeug bleibt in jeder anderen Hinsicht ein erstklassiges GP-Werkzeug:

• Der benutzerdefinierte Dialog sammelt und validiert Parameter und übergibt dann ein Standardparameter-Array an die normale GP-Ausführungspipeline – so wird der Lauf in der Geoverarbeitungshistorie aufgezeichnet, Umgebungs-Einstellungen beachtet, Fortschritt/Nachrichten gemeldet und Metadaten genau wie heute gestempelt.
• Kontexte, die den benutzerdefinierten Dialog nicht hosten können – ModelBuilder, Batch-Modus, geplante Ausführungen, Server-Publishing, arcpy – fallen automatisch auf das automatisch generierte Fenster und vorhandene Parameterobjekte zurück. Nichts bricht.
• Wenn kein benutzerdefinierter Dialog registriert ist, verhält es sich genau wie heute (vollständig abwärtskompatibel).

Stufe 2 – benutzerdefinierte Parametersteuerungen (eine kleinere aber dennoch transformative Anforderung). Ermöglichen Sie einem Entwickler, eine benutzerdefinierte WPF-Steuerung für einen einzelnen Parameter (oder einen benutzerdefinierten Parametertyp) zu registrieren, die im generierten Fenster gehostet wird. Selbst dies würde den Großteil des Problems beseitigen: Eine Wertetabelle könnte zu einem echten Raster mit Live-Feedback werden; ein Remap-Parameter könnte ein Histogramm des Eingabe-Rasters anzeigen; ein Schwellenwert könnte zeigen, welche Zellen er auswählt.

Warum es wichtig ist

Benutzerdefinierte Python-Toolboxen sind ein erstklassiger Erweiterungspfad für ArcGIS Pro, und Organisationen sowie Dritte bauen ernsthafte Analyse-Suiten in kommerzieller Qualität darauf auf. Die Qualität dessen, was der Benutzer sieht, wird nicht durch den Aufwand des Entwicklers begrenzt, sondern durch das generierte Fenster. Entwickler, denen die Benutzererfahrung wichtig ist, werden gedrängt, das Geoverarbeitungs-Framework aufzugeben – wodurch Herkunftsnachweise, Reproduzierbarkeit und Skriptbarkeit verloren gehen; genau die Dinge, die Pro-Werkzeuge vertrauenswürdig machen. Ein unterstützter UI-Erweiterungspunkt würde diesen Kompromiss beenden, die Qualitätsstandards des gesamten Drittanbieter-Ökosystems anheben und keinerlei Kosten bei der Abwärtskompatibilität verursachen.

JeffJenness

Konkrete Einschränkungen, die beim Erstellen eines echten Toolsets auftraten – alle begegnet (und unabhängig reproduzierbar) beim Portieren eines großen Wildtier-Analyse-Toolsets in eine Python-Toolbox in ArcGIS Pro 3.7. Jede ist für sich genommen handhabbar; zusammen zeigen sie, warum ein unterstützter Custom-UI-Weg notwendig ist. Mit 5c6 markierte Punkte sind auch Kandidaten ffcr einzelne Fehlerberichte fcber My Esri Support.

1. 5c6 Die Wert-Tabelle-Zellen-Verwaltung ist inkonsistent und undokumentiert. We4hrend der Dialogvalidierung kommt eine GPValueTable-Zelle, die eine Kartenebene oder Tabelle enthe4lt, als reiner Anzeigename an Text wenn sie hineingezogen wird, aber als Wrapper-Objekt (MappingLayerObject / MappingTableObject) dessen str() nur eine Repre4sentation ist (<MappingTableObject object at 0x026>) wenn es aus dem Dropdown der Zelle ausgewe4hlt wird. Validierungscode muss defensiv beide fangen; naiver str() Gebrauch erzeugt falsche "existiert nicht"-Fehler.
2. 5c6 Kein unterstfctzter Projektzugriff we4hrend der Validierung. arcpy.mp.ArcGISProject("CURRENT") ist unzuverle4ssig/unterstfctzt in updateParameters, daher kann ein Tool einen Layernamen nicht auf seine Datenquelle auflf6sen, um intelligente Standardwerte zu setzen (z.B. Vorschlag einer Begleit-Tabelle neben dem Eingabe-Raster in einer Geodatabase).
3. Kein Ausschalten der automatischen Namensvergabe ffcr Framework-Ausgaben. Wenn sich die erste Eingabe e4ndert, ffcllt Pro eine leere erforderliche Ausgabe mit <erste Eingabe>_<Toolname>. Bei Multi-Eingabe-Tools ist die erste Eingabe oft nicht das Thema der Ausgabe (z.B. ein Lebensraumfaktor von sechs), daher ist der Vorschlag verlässlich falsch – und das Tool kann ihn nicht unterdrfccken.
4. Keine Mf6glichkeit, den Startordner des Durchsuchen-Dialogs pro Parameter festzulegen, selbst wenn das Tool genau weidf, wo die relevanten Dateien liegen.
5. "Einmal vorschlagen, Benutzer le4sst es lf6schen" erfordert eine undokumentierte Vorgehensweise..altered unterscheidet keinen vom Benutzer gelf6schten Wert, daher he4ngen brauchbare Auto-Standards vom undokumentierten Verhalten von hasBeenValidated ab.
6. 5c6 Ein deaktivierter Ausgabeparameter, der noch einen Wert enthe4lt, lf6scht seinen Datensatz beim Ausffchren (Vorab-L46schung bei 2berschreiben-Ausgabe läuft vor execute()), obwohl der Parameter deaktiviert ist – eine Datenverlust-Falle bei Modus-Umschalt-Dialogen.
7. Keine Ein-/Ausblendung von Parametern und eingeschr2nkte Layout-Kontrolle. Kategorien-Gruppen werden immer unter allen unkategorisierten Parametern angezeigt, und Kategorien sind standardm2ig eingeklappt; ein Parameter kann nicht verborgen werden, wenn ein Modus ihn irrelevant macht.
8. Leere Wert-Tabelle-Zeilen, die mit "Weitere hinzuf5fcgen" erstellt wurden, werden entfernt, sobald das Fenster aktualisiert oder der Fokus verloren geht, sodass ein Benutzer nicht in einer frisch hinzugef5fcgten Zeile auf Durchsuchen klicken kann – und das Ziehen eines Layers auf die Steuerung f5fcgt auch keine Zeile hinzu. Die Dropdowns der Zellen sind die einzige verlässliche M5fgllichkeit zum Hinzuf5fcgen einer Zeile.
9. Rastereingaben k5nnen als CIMPATH=.../...json URIs in .valueAsText erscheinen, die arcpy.Describe/CopyRaster ablehnen, was stattdessen 5ber das Werteobjekt aufgelöst werden muss.
10. Keine benutzerdefinierten Widgets jeglicher Art. Kein Histogramm oder Vorschau eines Eingabe-Rasters, kein Live-Diagramm, keine Farbfelder, kein Rich Text. In unserer Suite musste ein interaktiver Remap-Tabellen-Ersteller als vollst2ndiges benutzerdefiniertes Add-in-Fenster geschrieben werden – wodurch die Geoverarbeitungsverlauf f5cr diesen Schritt verloren ging – weil das Fenster es einfach nicht hosten kann.
11. Die Multivalue-Wertlisten-Steuerung bietet immer "Alle ausw2hlen", selbst wenn das Auswählen aller semantisch falsch ist – z.B. eine Liste geografischer Transformationen, bei der genau ein Eintrag pro Datumspaar sinnvoll ist. Keine Toolbox-Eigenschaft unterdrückt oder benennt diese Option um.
12. 5c6 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.