Echtes Ausdokumentieren von Normal-GDLs

[Hmooslechner]

Echtes Ausdokumentieren von Normal-GDLs:

Ich bin schon sehr lange am rumprogrammieren im GDL und kenne mich soweit eigentlich ganz gut aus. ABER

Selbst mit meinen Kenntnissen ist es mir nur sehr schwer möglich, ein bestehendes normales Archicad - Bibliothekselement zu ändern oder an meine Bedürfnisse anzupassen, weil es keine umfassende Dokumentation der prgrammierten Struktur des GDLs gibt.

Wenn ich beispielsweise bei einer ganz normalen Terrassentüre unten eine gedämmte Stockaufdoppelung zum Abgrenzen des Bodenaufbaues programmieren will, muß ich es "irgendwie" dazuflicken, weil ich eigentlich nicht so einfach erkennen kann, wohin dies im Programm eigentlich gehört.

Viele Teilbereiche der Türe sind "ausgelagert" - also in externen "globalen"Scripten vorhanden, welche eben bei mehreren Türen dann eingebunden sind - was natürlich sinnvoll ist. Es fehlt aber eine einfache Nachvollziehbarkeit für den Anwender.

Vorhanden sind - wenn man Glück hat - manchesmal - englische Anmerkungen im GDL-Script..


MEIN WUNSCH:

Für alle Klassen von NORMALOBJEKTEN ein eigenes genau beschriebenes PDF wo was hingehört und wie es verbunden ist.

Also zB. ein Terrassentür - PDf mit vielleicht 25 Seiten mit der Darstellung aller eingebundenen Scripren, Beispielen bei Änderungen usw. komplett ausdokumentiert.


Also jeweils eigene PDF - Beschreibungen für:
Innentüren, Eingangstüren, Terrassentüren, Tore...eben alle in der Bibliothek vorhandenen Kategorien.

Außerdem müssten die eigentlichen Scripts VIEL INTENSIVER mit "!!!" ausdokumentiert werden. Eingebunden Fremd-Scripts sollten jeweils genau beschrieben sein - wo genau sie denn liegen usw.


GDL wurde als "offenes" System kreiert und scheitert meiner Meinung nach besonders am "Verschweigen" der Funktionalität und wird mit jeder AC-Version immer komplexer und unüberischtlicher "verschachtelt".

Dieses "Fehlentwicklung" lässt sich nur durch den kompromisslosen Einsatz von sinnvollen und vollständigen Kommentaren im Script und globalen erklärten Beispielen (PDFs) beheben.


Nicht einmal das GDL-Referenzhandbuch ist up to date... Folge mal dem Link auf der ersten Seite nach dem Inhaltsverzeichnis:

http://www.graphisoft.com/support/developer/documentation/LibraryDevKit.

Und Du bekommst mal direkt - nichts sinnvolles..

[Hmooslechner]

Jetzt habe ich wenigstens mal gefunden, wo die externen Scripts liegen...

Man muß die Bibliothek erst mal "entpacken". Dies hat den Vorteil, dass man das Original in Ruhe lässt, weil man mit Kopien arbeitet.


Dann findet man es zB. hier:

E:\AC17Bib\Objektbibliotheken 17\4. Macros 17\Dach Macros 17\Base Macros CHE 17

Eventuell global wirksame Zusatz-Scripts müsste man dann hier reinschreiben.


Das Problem dabei, was mir bisher so aufgefallen ist:

In diesen "globalen" Scripts werden in mehreren Ebenen die ursprünglichen Parameter immer wieder neu definiert und somit umbenannt- um etwa die verschiedenen Lokalisierungen D - A - CH zu bedienen.

Man muss nun alle diese Umbenennungen nachvollziehen können, um sinnvoll damit arbeiten zu können. Das heisst - ich muß mir für jeden Parameter im einzelnen GDL-Objekt anschauen, unter welchen Namen er übergeben wurde und wie er dann in den allgemeingültigen Scripts noch 1-2 x umbenannt wurde - zum Teil noch über "Felder"-Parameter.. ( zB. Name[n1] ) Und alles ist nicht richtig dokumentiert - kommentiert...

Man hat schon den Eindruck, dass Graphisoft eigentlich gar nicht will, das wir Anwender da was selber machen können... 👿

[Anonymous]

Ich denke es gehört nicht zu den Aufgaben eines Anwenders sich mit GDL-Programmierung zu beschäftigen. Mir ist ehrlich gesagt meine Zeit zu schade dafür und ich kann mir nur schwer vorstellen, dass sich das für 99,9 % der Anwender wirtschaftlich rechnet sich damit zu befassen. Es ist schön dass es die Möglichkeit gibt (ich hab mich auch schon damit befasst und deshalb ist mir meine Zeit zu schade) aber die Graphisoft Entwicklungs-Ressourcen wären mir auf vielen anderen Gebieten deutlich wichtiger. Wenn das eine extra Leistung wäre, die dann auch extra bezahlt werden muss wäre mir das recht. Ich möchte mit meinen Geld solche Leistungen nicht mitfinanzieren.

[Hmooslechner]

Ich würde Dir zustimmen, wenn die mitgelieferten GDLs vollständig und Anwender-freundlich wären.

Da sie das aber nicht sind, sollte wenigstens die Möglichkeit "offenstehen" - und nicht hinter vielen Ebenen des Herumspringens zwischen undokumentierten Scripten "versteckt sein", selber das Problem zu lösen.

Beispiel Terrassentüren - ohne untere gedämmte Stockaufdoppelung zum Abschluß des Bodenaufbaues nach Aussen - der im wirklichen Bauen einfach Standard ist.

Und Und Und..

Wenn es schon nicht in der mitgelieferten Bibliothek vorhanden ist, sollte es kein Problem sein, sowas selber reinzubauen.

Und wenn die Struktur der Bib. schon so aufgebaut ist, dass sich die einzelnen Bib-Elemente auf gemeinsame Scripts beziehen, sollte es besonders dort möglich sein - ohne lange Sucherei und nicht in jedem Element einzeln das Script wieder einfügen zu müssen..

Dies würde solche Arbeit für den Anwender weit wirtschaftlicher gestalten...

Da muß ich Dir recht geben - derzeit ist der eigene Einsatz in dieser Richtung viel zu Aufwändig und als Normalanwender wäre mir so wie es derzeit gelöst ist - auch das Geld zu schade es selber zu tun. Zugegebenermaßen befinde ich mich als Lehrer in einer viel einfacheren Position als Du.

Der immense Vorteil wäre einfach, dass die Entwicklung der Bibliothek von viel mehr Köpfen geschähe und damit viel schneller an den jeweiligen Bedarf angepasst würde. Dies käme letztlich Dir als Anwender zugute und Du könntest wirtschaftlicher Arbeiten.

Es würden also viele fremde Menschen für Dich gratis arbeiten 😁

[Anonymous]

"hmooslechner" wrote:

Der immense Vorteil wäre einfach, dass die Entwicklung der Bibliothek von viel mehr Köpfen geschähe und damit viel schneller an den jeweiligen Bedarf angepasst würde. Dies käme letztlich Dir als Anwender zugute und Du könntest wirtschaftlicher Arbeiten.

Davon halte ich nichts. Dieses Konzept hat enorme Schwächen je branchenspezifischer ein Programm ist. Außerdem setzt es voraus, dass die vielen privaten Entwickler wissen in welche Richtung es grundsätzlich gehen soll, und dass die privaten Helfer diese Richtung auch mitbestimmen können. Ansonsten fangen die fleißigen Helfer nach jeder dritten Version von vorne an.

"hmooslechner" wrote:
Es würden also viele fremde Menschen für Dich gratis arbeiten 😁

Ich wär schon froh wenn die die für mich gegen Geld arbeiten das machen was ich will 😉

[Hmooslechner]

Welch eine Utopie.. 😉

[Anonymous]

Ich wünsch mir ebenfalls eine bessere GDL Dokumentation.
Die muss es a auch geben, sonst würden die ganzen Graphisoft programmierer a selbst im Dunkeln tappen (Personalwechsel usw....)

@A_R_S
Ich kann zwar verstehen, dass du dir das nicht wünscht, allerdings ist es mir unverständlich, dass du durch deine intensive Gegenargumentation den Wunsch schon fast boykottierst. Du hättest keinen Vor- oder Nachteil egal ob der Wunsch umgesetzt wird, oder nicht.