Hi Bertrand,

with pythonnet you connect Python with e. g. a C#/WPF assembly. This assembly can use the Allplan assemblies with the Allplan WPF controls, which are exist for your mentioned value types.

We also plan to improve PythonParts interface (*.pyp) to have at least the same possibilities as with the SmartParts. But we also need to know what's currently missing. Please inform me about this.

Best regards
Horst

Großartig, das man mit pythonnet WPF-Componenten benutzen kann, wußte ich nicht! Sorry!

Kann man diese WPF-Dialoge auch mit eine PythonPart (ohne den Interactor) benutzen?
Oder wenn das nicht geht, wie erzeuge ich ein modifizierbares PythonPart mit einer benutzerdefinierten Eingabefunktion
(Interactor=True)?

Zu den "dynamischen" (gescripteten) Controls in der Palette: Sicher braucht man das nicht immer, deshalb wäre eine
zusätzliche optionale gescriptete UI sicher hilfreich.
Bei den statischen Controls wäre es aber eine enorme Hilfe, wenn Multi-Edit funktionieren würde.
(Da haben wir bei den SmartParts leider zu spät dran gedacht!)
Mit statischen Controls ist das nicht schwer zu implementieren (s. py_multi_edit.mp4)

Dass sich zukünftig gleiche PythonParts auf Nachfrage aktualisieren ist schon mal ein Schritt, mit diesem Manko umzugehen.
Da würde ich mir wünschen, das je PythonPart einstellen zu können. Manche PythonParts brauchen diese Art der
Gleichheitsüberprüfung nicht!

Eine weitere Erleichterung (für den Vertrieb der PythonParts) wären noch 2 Dinge:

-Autarkheit: Das PythonPart auf dem Teilbiild muss autark funktionieren, ohne zusätzliche py-Dateien installieren zu müssen
Sprich: das Script muss dann sicherlich am PythonPart gespeichert werden.

-Schutz: Gute PythonParts zu programmieren erfordert einigen Aufwand.
Den möchte man sich ggf. vergüten lassen, indem man die PythonParts verkauft/lizensiert.
Zumindest sollte das Python-Script mit einem Passwort geschützt werden können, damit man dort ggf. weitere Schutz- bzw. Lizensierungsfunktionen einbauen kann. (s. SmartParts von Bertrand/difraxis)

Der Hinweis auf die spärliche Dokumentation ist sicherlich auch berechtigt.
Das zitierte Beispiel ValueList.pyp ist leider alles andere als selbsterkärend.
Es hilft doch allen, wenn man leicht an die notwendigen Informationen kommt, ohne rumprobieren zu müssen.

..alles richtig! Trotzdem wird das Script doch durch das Allplan-Python-Framwork von einer bestimmten Stelle geladen und eine neuen Eingabefunktion (der Interactor) erst dann gestartet. Beim PythonPart genauso!
Beides funktioniert nicht, wenn nur die vorkompilierte .pyc-Datei vorhanden ist. (...falls Du das mit ByteCode gemeint hast)
"Danach", wenn das Script geladen ist, oder dem Python-Interpreter zu ausführung übergeben wurde, kann man sicher alles machen, was in Python erlaubt ist!

Das Laden der .py-Datei durch das Allplan-Python-Framwork müßte ja dann auch das Laden von Bytecode oder sogar verschlüsselter
Scripte erlauben! Es ist doch nicht so schwierig, die py-Datei beim Laden zu entschlüsseln, und dann erst zu starten.
Das könnte man performant im C++ machen, und hätte den Vorteil, das das dann schon mal etwas schwerer zu umgehen ist.

Mit diesem Schutz kann man dann im Python-Script eine komfortable Lizensierung aufbauen, ggf. sogar mit Echtzeit-lizensierung über
einen Lizenzserver.

Und zurück zur Frage mit WPF in Allplan:
Für C++ gibt es diverse Service-Klassen, um z.B. den WPF-Dialog als Allplan-Palette anzeigen zu können.
Die statische .pyp-Datei benutzt diese, um die Controls in der Palette anzuzeigen.
Sicher ist es möglich, auch das C++ CLI/CLR Dialog-Framwork mit Python-Bindings zu versehen.
Spätenstens wenn man z.B. im pythonnet-WPF-Dialgog Controls haben möchte, die auf Allplan-Ressourcen zugreifen müssen
(wie Schraffuren, Muster, Stilflächen, Layer usw.), braucht man diese Service-Klassen in Python dafür.
Diese Controls brauchen das Binding an ein sogenanntes CommonControlsInit-Objekt, damit sie funktionieren.
Das wird aber sicher als nächstes kommen...