Hotspot Übergabe bei Call Aufrufen

[Hmooslechner]

Hotspot Übergabe bei Call Aufrufen - oder auch bei Geländer, Stiege und Fassaden-GDLs:






https://www.youtube.com/watch?v=r5gQJmBmHkk

Nochmals:

Man kann mit "call" GDLs innerhalb GDLs aufrufen.

Wenn diese allerdings Hotspots inkludiert haben, und man die aufgerufenen GDLS dann öfter einsetzen will, bekommt man Fehlermeldungen, weil die ID-Nr. für jeden Hotspot eindeutig sein müssen und bei Wiederholungen dann aber mehrfach auftreten.

Ist eigentlich "Blödsinn", weil die Hotspots aus den aufgerufenen GDLs eh nicht auf den GDL-Aufrufer übergeben werden.


Wunsch 1:

Graphisoft sollte diese Fehlermeldung in diesem speziellen Fall ignorieren - entfernen! (Oder die Hotspots an den User doch übergeben).

Wunsch 2:

Bei Fassaden-GDLs, Geländer und Stiegen-Elementen werden eingetragene Hotspots auch nicht mit übergeben - was in diesem Fall schade ist, denn dann wäre eine User-basierte Editiermöglichkeit gegeben. Bitte Hotspots in GDLS für Geländer, Treppen und Fassadenelementen "durchschalten".

[Frank Beister]

Die Hotspots können nicht übergeben werden, weil sie ein abstraktes Konstrukt sind.

Mit dem Hotspotbefehl definiert man die Veränderung von Objektparametern (Achtung, nicht Variablen) und nicht etwas, was einen Inhalt hätte und übergeben werden könnte.
Beim CALL eines Objektes muss das aufrufende Objekt exakt diese Parameter ebenfalls angelegt haben. Gleicher Name, gleicher Typ und v.a. beim CALL Übergabe der Werte, die im Hauptobjekt abgelegt sind. Dann funktioniert auch der bewegliche Hotspot. Und ergibt auch Sinn und bietet erhebliche Möglichkeiten der Skriptstrukturierung.

Bei der Platzierung eines Objektes, das andere aufruft, werden in der Projektdatei nur diejenigen Parameter abgelegt, die in dem aufrufenden Objekt definiert wurden, NICHT aber die der Makroobjekte. Deren Existenz oder gar Inhalte werden hierfür ignoriert.

[Hmooslechner]

Ignoriert - aber nicht in den Fehlermeldungen. Wenn es ignoriert werden würde, dann hätte ich ja kein Problem damit, denn dann könnte ich mit simplen call Befehlen auch Beliebige sessel-GDLs reinholen. Geht aber nicht. Deren Hotspots brauch ich ja gar nicht. Wäre schön, wenn es ignoriert werden würde.

Dies wäre ja mein Wunsch: Wenn im ge-calltenm Objekt Hotspots vorhanden sind - einfach ignorieren. Ohne Fehlermeldungen. Wenn ich sie mit Parameter und Werteübergabe aber schön Weiterzähle, könnte es ja trotzdem funktionieren. Einfacher für den User machen!

[Frank Beister]

Ich sprach davon, dass die Parameter der Makroobjekte für die Speicherung in der Projektdatei ignoriert werden.

Dass Befehle, die in dem aufgerufenen Kontext einfach falsch sind, Fehlermeldungen verursachen ist doch normal und soll ja auch so sein. Wie willst du sonst ein Skript prüfen, wenn mögliche Skriptfehler nicht gemeldet werden?

Brechen die als Makro aufgerufenen Stuhlskripte eigentlich einfach ab, oder werden nur Fehlermeldungen ausgegeben? Wenn es nicht abbricht, was ich vermute, ist doch alles gut. Quick and dirty ist halt nicht nur quick, sondern auch dirty. 😄

Du kannst übrigens jederzeit prüfen, ob ein Skript als Makro läuft und dann die HOTSPOTs nur bedingt ausführen.

[Hmooslechner]

Probiers mal einfach aus - mit dem Designstuhl einfach eine wiederholende Reihe machen - Viel Vergnügen! Die Hotspots werden dabei in mehreren Ebenen Call Aufrufen weitergeleitet - Da hab ich - und ich bin kein GDL-Neuling - keine Chance.

[Frank Beister]

Das glaube ich dir ja, Heimo. Aber du "verlangst" von einem Objekt etwas zu leisten, wofür es nicht programmiert wurde. Der Designstuhl ist ganz offensichtlich nicht dafür vorgesehen mehrfach als Makro aufgerufen zu werden.
Dein Wunsch keine Fehlermeldung auszugeben, damit er irgendwie trotzdem funktioniert. halte ich nicht für sinnvoll, denn die Fehlermeldungen ergeben bei der regulären Programmierung einen Sinn. Die sind bei GDL, das weißt du selber, zu wenig, falsch und unvollständig genug. Wenn ich einen Fehler mit den Fangpunkten programmiert habe, möchte ich dass AC mich darüber informiert und das nicht ignoriert.
Dass solche Objekte, die potentiell als Makros aufgerufen werden könnten, per se einen Übergabeparameter für die Startnummerierung haben sollten, ist ein anderer Wunsch.

[Hmooslechner]

Lieber Frank!

Stimmt! Ich würde gerne mit minimalstem Aufwand Objekte in mein GDL hereinrufen können.
Es ist mir vollkommen egal, welche "internen Zahnrädchen" sich dabei im Hintergrund drehen müssen.

Ich möchte, dass es auf einfachste Weise möglich wird.
Bei mir gibts normalerweise das Motte: "Geht nicht gibts nicht"



Von Dir höre ich:

Es würde das schöne System der "internen "Zahnrädchen" stören. Deshalb sollte es nicht gehen.

Welcher unserer beiden Ansichten ist wohl lösungsorientierter?

[Frank Beister]

Dann lies meine Postings richtig, bevor du mich falsch interpretierst. Und schreibe mal ein Skript mit 10t Zeilen plus ohne funktionierende Fehlermeldungen. 🙂

[Hmooslechner]

Lieber Frank!

Entschuldige, wenn ich Dir ein wenig zu nahe getreten bin - war nicht meine Absicht!

Dein Argument, dass Fehlermeldungen wichtig sind, derzeit unvollständig (zum Teil auch missverständlich), sehe ich natürlich genauso.

Das ist nicht mein "Angriffspunkt".

Was ich mir wünsche, sind nicht weniger Fehlermeldungen, sondern eine andere Funktionalität des GDL, eine andere - erweiterte Funktionalität, die es dem User einfacher macht, sein gewünschtes Ergebnis zu verwirklichen.

Jene Programmierer, die gerne sauberen Code erzeugen, sollen selbstverständlich voll unterstützt werden - sogar intensiver, sicherer, informativer als jetzt. Dass man beispielsweise Sublime nimmt, weil Archicad selber keine Weiterentwicklung des eigenen Editors zuließ, finde ich - (sch)...ade- ..

Aber jene Programmierer, die gerne auch mal schnell "quick and dirty" arbeiten, sollten meiner Meinung nach nicht durch Kleinigkeiten behindert, sondern im Lernprozess unterstützt werden.

Ist sicherlich auch ein Argument, was helfen würde, mehr Normaluser für das GDL zu begeistern als jetzt, wenn man nicht immer sofort an der Komplexität des derzeitigen GDL's "ansteht".

Es spricht sicherlich nichts dagegen, dass ein sorgfältiger Scripter sich alle Hotspots aus allen internen Call-Aufrufen sauber zusammensucht und sie durch alle Instanzen durchschaltet. Wunderbar!

Aber - für Frischlinge kann sowas sehr frustrierend sein.

Was spräche denn wirklich dagegen, GDLs mit Call aufzurufen und einfach die internen Hotspots zu ignorieren, wenn man sie im eigenen Sammel GDL gar nicht braucht? Jetzt muss ich mich mit Scripten selber bemühen, unbrauchbares auszufilern. Das wäre alles unnötiger Aufwand, wenn Archicad einfach die eigene dahinterstehende Logik um das Ignorieren der Hotspots erweitern würde.

Ich will nicht weniger! - Ich will mehr!

[Frank Beister]

Du bist mir nicht zu nahe getreten. 😉

Die Befehle zu den Fangpunkten sind gelinde gesagt Bullen****. Sie sind aber jetzt so lange etabliert und in Objekten enthalten, dass sie aus GDL nicht mehr verschwinden werden. Auch wenn es bessere, verständlichere Befehle als Ersatz gäbe. -> Anderes Thema.

Ich verstehe schon, wo du hinwillst. Aber technisch gibt es nur zwei Möglichkeiten:

Entweder die fehlerhaft programmiereten (und das sind sie, wenn du den Stuhl zweckentfremdet als Makro verwendest) Hotspots werden per se ignoriert. Es kommt zu dem von mir zuvor erwähnt inakzeptablen Zustand der fehlenden Fehlermeldungen. Wahrscheinlich mit einhergehender Disfunktionalität assoziierter Maßketten.

Oder GS führt einen speziellen Q&D CALL Befehl ein, bei dem wahrscheinlich dann immer noch das Problem mit den Maßketten entsteht.

Aber wieviele Sonderbefehle soll GS denn einfügen, um Programmierfehler ignorieren zu können. Ich bemühe mal ein Beispiel:

Ich kann kein Porsche 911er Getriebe in einen Polo einbauen. Auch wenn das ein super Getriebe ist und ich es gerade zur Hand habe. Ein Porschegetriebeadapter wäre zwar hilfreich, aber was sollte VW denn dann noch liefern? Einen Ferrari-Turboladeradapter und einen Citroen-Bremsenadapter?

GDL wird nicht das Alltagstool des Architekten. Jedenfalls so lange es keine Library Part Maker 10.0 gibt. Daher ist es auch irgendwie logisch, dass der Editor nicht weiterentwickelt wird. Dafür aber die Schnittstelle zu externen Editoren. -> Archicad 23 / XML-Konverter.

Zurück zu deinem Wunsch: Das Vorrichten solcher Bibliothekselemente, die seriell verwendet werden könnten für einen unkomplizierten Makroaufruf. DAS ist für mich der Wunsch. In diesem Fall also die Erweiterung um einen Übergabeparameter des Startwertes der Hotspots oder einen Schalter fürs Abschalten. Oder beides in einem: 0=Abschalten. Und das IM OBJEKT, nicht als GDL-Funktionalität.