Das Wissen aller Anwender nutzen

Im Allplan Connect Forum tauschen sich Anwender aus, geben wertvolle Tipps oder beraten sich bei ganz konkreten Aufgabenstellungen − auch international.
Und damit wirklich keine Frage unbeantwortet bleibt, unterstützen die Mitarbeiter des Technischen Supports ebenfalls aktiv das Forum.

Es erwarten Sie:

  • Foren-Vielfalt aus CAD Architektur, CAD Ingenieurbau uvm.
  • Tipps von User für User
  • international: Deutsch, Englisch, Italienisch, Französisch und Tschechisch

Melden Sie sich jetzt an und diskutieren Sie mit!

Zur Registrierung

[Frage] Unterstützung von SYMB_POS [Gelöst]

Schlagworte:
  • Smartparts
  • Allplan
  • 2019
  • SYMB_POS
  • Plugin-Download

Hallo.

Ich bin über den Befehl SYMB_POS gestolpert. Wenn ich das richtig verstanden habe, müsste hiermit die Lage eines Smartparts im Dokument verändert werden können. Der Befehl wird in Allplan 2019 nicht unterstützt aber ist es geplant irgendwann mal damit arbeiten zu können?

Bzw. gibt es eine Möglichkeit wie ich die aktuellen Koordinaten des Smartparts beim Öffnen einlesen kann? Dann könnt ich das, was ich erreichen will über einen Umweg einbauen..

Danke schon im Voraus!

Lösung anzeigen Lösung verbergen

Gerade weil die Gleichheitsprüfung die Information von SYMB_POS und SYMB_ROT "nicht sieht" bzw. ignoriert, bekommt man ja diese Probleme mit der Gleichheitsprüfung! Dadurch ist das Versprechen : Gleiche Paramter und gleiches Script erzeugen dasselbe Ergebnis nicht länger gültig! Der Hashwert über Script und Parameter würde "Gleichheit" anzeigen, obwohl die SmartParts unterschiedliche Geometrien haben!

Und der Layer der Makroverlegung wird nicht geprüft, weil es sich nicht um einen Parameter, sondern um eine "äußere Eigenschaft" des SmartPart-Containers handelt! Sehr wohl aber wird eine Parameter "lay", der zusammen mit dem Befehl LAYER lay im Script vorkommt, in die Gleichheitsprüfung einbezogen!

Die Parameter, über die der Hashwert gebildet wird, haben alle ein "+" in der Spalte "G".
Damit kann man Parameter mit "-" in der Spalte auch von der Gleichheitsprüfung ausschliessen, wenn diese nicht "in die Geometrie" bzw. in das "Aussehen" des SmartParts "eingehen". Z.b. wenn ein Parameter nur die aktuelle Seite in der Palette anzeigt ("curr_page"), braucht man den nicht für die "Gleichheitsprüfung"! Das wäre eher hinderlich!

Man könnte aber SYMB_POS und SYMB_ROT zu Standard-Parametern machen, wie REF_X und REF_Y.
Dann würden diese in die "Gleichheitsprüfung" eingeschlossen.
Das könnte allerdings nur Allplan machen.

Aber, mit Allplan 2021 kann jeder Folgendes als Workaround machen:
1. Attribute anlegen "Pos_X", "Pos_Y" und "Pos_Z" als Formel-Attribute mit Verweise auf die Attribute
Allplan_intern->X_Koordinate(163) Allplan_intern->Y_Koordinate(164) Allplan_intern->Z_Koordinate(165)
und diese dem SmartPart zuweisen

2. Im Script Parameter "pos_x", "pos_y" und "pos_z" anlegen, und diese an die Attribute "Pos_X", "Pos_Y" und "Pos_Z" verknüpfen.

3. Danach kann man im Script auf die Werte zugreifen.

Kleiner Haken an der Sache ist, dass das SmartPart die Verschiebung bzw. die Änderung des Attributes "nicht mitbekommt".
Daher muss man danach noch ein "SmartPart aktualisieren" machen.

Aber als Workaround mag es ausreichen!
Entdeckt die Möglichkeiten (der Formelattribute)!

Anhänge (1)

Typ: text/xml
1066-mal heruntergeladen
Größe: 7,72 KiB
1 - 10 (13)

Hallo,

No, SYMB_POS and SYMB_ROT are not implemented and I think they never will be.
It is not possible to know the coordinates of the insertion point of a SmartPart nor its orientation.
___________

Nein, SYMB_POS und SYMB_ROT sind nicht implementiert und ich denke, sie werden es niemals sein.
Es ist weder möglich, die Koordinaten der Einfügemarke eines SmartParts noch dessen Ausrichtung zu kennen.


Ich erläutere gern nochmal das Problem, welches sich dahinter verbirgt:

Das Ergebnis einer SmartPart-Erzeugung besteht aus Makro-Definition und Makro-Verlegung.
Diese beiden Elemente werden im Teilbild gespeichert!

Als Anwender sieht man nur die Makroverlegung, die Definition ist nicht sichtbar.
In der Definition befinden sich die Folien mit den Geometrie-Elementen, die durch die Makro-Verlegung
an der Stelle der Verlegung im Teilbild verschoben, gedreht und verzerrt dargestellt werden.
Die Definition ist eine Art "lageunabhängige" Geometrie-Vorlage, die durch die Verlegung an den konkreten Ort "transformiert" wird.

Solange man nur ein SmartPart (Makro-Verlegung) auf dem Teilbild/den Teilbildern hat, ist alles OK!
Wenn man jedoch das SmartPart an eine andere Stelle oder auf ein anderes Teilbild kopiert, wird nur die Makro-Verlegung kopiert,
d.h. es "teilen" sich 2 Makro-Verlegungen eine Definition.

Dadurch wird jegliche Änderung an der Definition (wie z.B. bei Makro-Modifizieren) automatisch und ungefragt auf
alle Verlegungen übertragen, auch Teilbild übergreifend.
Für Makro-Definitionen auf 2 getrennten Teilbildern, wird zur Überprüfung der "Gleichheit" der Zeitstempel der letzten Änderung der Makro-Definition herangezogen. So werden auch kopierte Definitionen auf anderen Teilbildern gefunden.

Die Scripte und alle Parameter des SmartParts sind in der Makro-Defintion gespeichert.
Bei den SmartParts wird nach einer Änderung (an einer Definition) gefragt, ob "gleiche" SmartParts mit geändert werden sollen.
Für SmartParts wird dabei die "Gleichheit" mit einem Hash über die Parameter-Werte und die Scripte geprüft.
Die Annahme dabei ist: Wenn die Scripte die Parameter-Werte gleich sind, ist auch der Script-Durchlauf und die Ergebnisse (die erzeugten Geometrien auf den Folien) identisch.

Wenn jetzt im Script mit SYMB_POS und SYMB_ROT Parameter der gerade geänderten Makro-Verlegung in den Script-Durchlauf eingebaut werden können, ist die obige Annahme nicht mehr gültig, und der Hash-Wert zum Vergleich nicht mehr geeignet!

Was wird passieren?
Wenn ich ein SmartPart ändere, und im Script für SYMB_POS und SYMB_ROT jeweils die Werte der aktuellen Verlegung "eingesetzt" werden, wird das SmartPart plötzlich "lageabhängig" erzeugt. Das Script-Ergebnis (Geometrie) würde an die Drehung (SYMB_ROT) der aktuellen Verlegung angepasst. Wenn es jetzt noch andere SmartParts gibt, die dieselbe Makro-Definition verwenden, werden diese mit aktualisiert, auch wenn sie vielleicht eine andere Drehung haben! Bei der Position(SYMB_POS) wird es noch komplizierter!
Meistens haben SmartParts unterschiedliche Positionen. Das Script kann immer nur die korrekte Geometrie für die Position der aktuellen Verlegung berücksichtigen. Andere Verlegung werden dann die für ihre Position falsche Geometrie erhalten!

Das bedeutet:
Mit der Freigabe von SYMB_POS und SYMB_ROT dürften sich dann nicht mehr mehrere Makro-Verlegungen eine Definition teilen!
Die Gleichheit könnte nicht mehr zuverlässig geprüft werden. Die "Aktualisierung von Gleichen" müßte komplett abgeschaltet werden.

Bei der Abwägung der Alternativen hat man sich entschieden, dass das Feature "Aktualisierung von Gleichen" zusammen mit der "Teilung" der Definition für mehrere Verlegungen bei Weitem mehr Möglichkeiten schafft, als die Freigabe von Freigabe von SYMB_POS und SYMB_ROT. Gerade weil man bei "massenhaft" vorkommenden SmartParts keine andere Möglichkeit des "Multi-Edit" anbieten kann!
Auch eine "differenzierte" Behandlung von "lageabhängigen" SmartParts (mit SYMB_POS und SYMB_ROT) und "lageunabhängigen" SmartParts (ohne SYMB_POS und SYMB_ROT) erschien zu aufwändig und unverständlich.

Möglicherweise sieht man das aber mittlerweile anders...

Hi Nemo,

This explanation clearly shows the "internal" view of the operation. Thank you.
But it is also conceivable to be able to use this information (position and orientation in the drawing).
The equality check might very well ignore this information, just as it does not consider the current layer, color, etc.
Often the goal of a programming system is to allow the user to do what the development team has not or cannot do. It is therefore desirable to have as few limits as possible.
Moreover, with time and the feedback of experiences, possibilities or limits can be reconsidered to offer a better tool.
But it's a recurring debate...


Gerade weil die Gleichheitsprüfung die Information von SYMB_POS und SYMB_ROT "nicht sieht" bzw. ignoriert, bekommt man ja diese Probleme mit der Gleichheitsprüfung! Dadurch ist das Versprechen : Gleiche Paramter und gleiches Script erzeugen dasselbe Ergebnis nicht länger gültig! Der Hashwert über Script und Parameter würde "Gleichheit" anzeigen, obwohl die SmartParts unterschiedliche Geometrien haben!

Und der Layer der Makroverlegung wird nicht geprüft, weil es sich nicht um einen Parameter, sondern um eine "äußere Eigenschaft" des SmartPart-Containers handelt! Sehr wohl aber wird eine Parameter "lay", der zusammen mit dem Befehl LAYER lay im Script vorkommt, in die Gleichheitsprüfung einbezogen!

Die Parameter, über die der Hashwert gebildet wird, haben alle ein "+" in der Spalte "G".
Damit kann man Parameter mit "-" in der Spalte auch von der Gleichheitsprüfung ausschliessen, wenn diese nicht "in die Geometrie" bzw. in das "Aussehen" des SmartParts "eingehen". Z.b. wenn ein Parameter nur die aktuelle Seite in der Palette anzeigt ("curr_page"), braucht man den nicht für die "Gleichheitsprüfung"! Das wäre eher hinderlich!

Man könnte aber SYMB_POS und SYMB_ROT zu Standard-Parametern machen, wie REF_X und REF_Y.
Dann würden diese in die "Gleichheitsprüfung" eingeschlossen.
Das könnte allerdings nur Allplan machen.

Aber, mit Allplan 2021 kann jeder Folgendes als Workaround machen:
1. Attribute anlegen "Pos_X", "Pos_Y" und "Pos_Z" als Formel-Attribute mit Verweise auf die Attribute
Allplan_intern->X_Koordinate(163) Allplan_intern->Y_Koordinate(164) Allplan_intern->Z_Koordinate(165)
und diese dem SmartPart zuweisen

2. Im Script Parameter "pos_x", "pos_y" und "pos_z" anlegen, und diese an die Attribute "Pos_X", "Pos_Y" und "Pos_Z" verknüpfen.

3. Danach kann man im Script auf die Werte zugreifen.

Kleiner Haken an der Sache ist, dass das SmartPart die Verschiebung bzw. die Änderung des Attributes "nicht mitbekommt".
Daher muss man danach noch ein "SmartPart aktualisieren" machen.

Aber als Workaround mag es ausreichen!
Entdeckt die Möglichkeiten (der Formelattribute)!

Anhänge (1)

Typ: text/xml
1066-mal heruntergeladen
Größe: 7,72 KiB

.... ich war zu langsam, um auf das "hidden feature" hinzuweisen....

Damit könnte man für Fenster Windlastklassen oder sowas ähnliches in Abhängigkeit von der Höhe angeben ;)

Namenlos gezeichnet in vollem Bewusstsein - ignorant, in eigen Augen vermutlich höflich, dennoch unhöflichst, unfreundlichst wer einen/viele vermutete - sich von alters erschließende Namen nennt.
[b]

Thank you Nemo for this trick.

I admit that I haven't searched again recently using this tip.
Indeed, it is necessary to update the SmartPart to obtain the current value, which can be a source of error.

I inserted your SmartPart and I created the 3 custom attributes with formula. It works very well.
Then, I modified one of my SmartParts by associating the attributes exactly like you and there, it always gives 0...
What am I doing wrong?


Anhänge (2)

Typ: image/png
23-mal heruntergeladen
Größe: 16,40 KiB
Typ: image/png
20-mal heruntergeladen
Größe: 15,80 KiB

Hast Du die Attribute NEU an die Parameter zugewiesen?

Du musst die definierten Attribute auch an das SmartPart zuweisen!

Anhänge (2)

Typ: image/png
33-mal heruntergeladen
Größe: 53,75 KiB
Typ: image/png
17-mal heruntergeladen
Größe: 126,53 KiB

Yes, I did all of that!
Besides, it works with your SmartPart.
I will find...
Thank you.


I recreated a new SmartPart and it works.
I don't know what could have happened with the other SmartPart...


1 - 10 (13)