Hallo Fredo,

diesen Editor gibt es bereits! Die Funkiton heisst: "Attribute übertragen".

Allerdings fehlt in Allplan dafür (schon immer) die Voraussetzung:

Alle Parameter eines Elements müssen in Attributen gespeichert sein, und über diese nicht nur auswertbar, sondern auch änderbar sein!

Bei Wand, Decke und anderen Bauteilen kann das nur Allplan umsetzen!

Bei den SmartParts kann das jedoch jeder selbst tun:
Einfach den Parameter (in diesem Fall die Stilflächennummer) mit einem Attribut verknüpfen. Fertig.
Danach kann man auch mehrere SmartParts mit "Attribute übertragen" durch Setzen dieses Attributes ändern, da im Anschluss an die Attribut-Änderung eine "Refresh" des SmartParts ausgelöst wird.

Warum hat man das nicht gleich von Allplan-Seite aus gemacht?
Zum einen, weil für die unzähligen Parameter in einem Fenster derzeit nicht genügend Standard-Attribute zur Verfügung stehen! Und weil man gehofft hatte, durch den bei Fenster hohen Wiederholungsgrad mit der oben genannten Frage nach der Aktualisierung gleicher SmartParts das Problem nicht zu Einem werden zu lassen.

Die Altenative wäre gewesen, die Standardfenster doch wieder klassisch (als Beuteil-Modellierer) zu implementieren. Dann hätte man (wie bei den Tragwerksobjekten auch) leicht ein Multi-Edit implementieren können. Aufgrund der Script-Sprache ist ein Multi-Edit von Parametern, und noch dazu in einem Element mit einer derart komplexen und baumartigen Struktur wie es bei den Fenstern der Fall ist, nicht umsetzbar!

Die Smartparts (und auch Makros) sind, meiner Meinung nach, in einer Sackgasse und nicht wirklich verbesserbar. Die mögliche Lösung sollte Sketchup-Komponenten-ähnlich sein. Jetzt sind sie zu komplex und, was mich am meisten stört, deren Raumzugehörigkeit ist immer noch nicht eindeutig gelöst - also sind sie nicht richtig auswertbar.

..das kann man so nicht stehen lassen.

1. SmartParts kann jeder verbessern oder gar neue erzeugen, da es eine offene Script-Sprache ist

2. durch die Programmierung mit einer Script-Sprache sind den Möglichkeiten keine Grenzen gesetzt.
Eine Sackgasse kann ich darin nicht erkennen.

3. Sketchup-Components sind erst mal dasselbe wie Makros, nämlich statische Container.
Erst die Dynamic-Components haben benutzerdefinierte Parameter, die man für verschiedene vordefinierte Operationen (Kopieren)
oder als Erstellungs-Parameter benutzen kann! Damit bekommt man aber niemals so flexible Objekte hin, wie mit einem Script.
Übrigens gibt es für solche Objekte eine Script-Sprache auch in Sketchup -> heisst Ruby!

4. Die SmartParts sind keineswegs zu komplex, sondern bilden genau das ab, was der Anwender in der jeweiligen Planungsphase braucht.
Ob Türgriffe oder nicht (nur so kann ich mir das Bild erklären) entscheidet der Anwender!

5. Die Raumzugehörigkeit ist eindeutig gelöst. Die Tür gehört zu dem Raum, in die sie schlägt.
Dass das in manchen Fällen nicht das ist, was der Anwender gerade möchte, steht auf einem anderen Blatt.

Ich betrachte das ohne Emotionen: in der nahen Zukunft werden smarte Produktbibliotheken samt Optionen von den Produzenten geliefert. Auf bimobject.com sind bereits jetzt 130.000 Objekte für Revit, 55.000 für Archicad, 30.000 für Sketchup und 160 für Allplan verfügbar. Dass es nicht rund läuft, liegt auf der Hand.
Zu 4. ( die Auswahl der Türklinken in dem Spart-Part Assistenten würde die Diskussion sprengen, also gab isch es auf)
Zu 5. die Raumzugehörigkeit der Türe ist eindeutig, das stimmt. Nur niemand braucht sie so, weder Architekten, noch die Bauherren, noch Produzenten, noch Facility Manager. (Über Türlisten diskutieren wir aber auch erst seit 10 Jahren). Manche Türen schlagen einfach nach aussen, dort wo es keinen Raum gibt, es ist ein technisches Problem - also lösbar...