abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du: 
abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du: 
Für den Samstag, den 19. Oktober, zwischen 16:00 und 18:00 Uhr (MEZ) ist eine technische Wartung geplant. Folgende Prozesse können dabei bis zu 60 Min ausfallen: Lizenzschlüssel hochladen, herunterladen, aktualisieren, SSA-Validierung und der Zugriff auf den Lizenzpool. Wir entschuldigen uns für die dadurch entstandenen Unannehmlichkeiten.
Programmierung
Alles über Programmierung in GDL und Python

A U F R U F - G D L - V A R I A B L E N N A M E N

Hmooslechner
Rockstar
Von Archicad-Version zu Version ändert sich auch die Bibliothek. Öffnet man nun Jahre später alte Archicad-Dateien - stimmen sehr oft die Bibliothekselemente nicht mehr überein.

Teilweise aus dem Grund, daß Variablennamen geändert wurden...

Mein AUFRUF:

Stellen wir eine Datenbank - Liste mit Variablennamen für Bibliothekselemente zusammen.

Wird dann später ein Element "verbessert", hält man sich an die Namen der Datenbank und keiner hat aus den Änderungsgründen später Probleme.

Dazu gehört auch, daß zusammengehörende Elementgruppen die gleichen Variablennamen erhalten sollten. So wäre gewährleistet, daß eine globale Änderung über alle aktivierten Elemente nur jene Gruppe ändert, welche man ändern will.
Bsp-Kücheneinrichtungen - Materialien, Stiftfarben usw.

[ 16-09-2002, 11:23: Beitrag editiert von: Heimo ]
AC5.5-AC27EduAut, PC-Win10, MacbookAirM1, MacbookM1Max, Win-I7+Nvidia
6 ANTWORTEN 6
Hmooslechner
Rockstar
Folgende Felder sollte diese Datenbank beinhalten:

1: eindeutige Nummer
2: Art: zB. Kücheneinrichtung, Sprossenfenster usw..

3: Archicad-Version
4: Kurzbeschreibung - 20 Wörter oder so
5: Prameternamen mit Kurzbeschreibungen
6: Regeln zum Weiterprogrammieren, Hinweise usw.
7: Datum der letzten Änderung
8: Authoren mit Datum der letzten Änderung

usw..

Bitte um ergänzende Fortsetzungen..

[ 16-09-2002, 11:21: Beitrag editiert von: Heimo ]
AC5.5-AC27EduAut, PC-Win10, MacbookAirM1, MacbookM1Max, Win-I7+Nvidia
Hmooslechner
Rockstar
Hat hier irgendwie wenig Wirkung...bisher.. :hot:
AC5.5-AC27EduAut, PC-Win10, MacbookAirM1, MacbookM1Max, Win-I7+Nvidia
Anonymous
Nicht anwendbar
ich glaube der ansatz ist nicht schlecht... aber zu theoretisch. nenn das kind lieber eine datenbank von frei verfügbaren gdl-objekten, die entsprechende benennung würde dann die datenbank automatisieren, indem sie einfach das objekt aus den feldbestandteilen heraus umbenennt. damit würde die einheitliche benennung quasi im nebenbei erledigt und der nutzeffekt für den anwender steht im vordergrund... eine relativ komplette objektsammlung...
Hmooslechner
Rockstar
Is mir zu hoch...??

Ich habe eher folgendes Problem mit alten Bibliotheken:

Die Variablennamen unterschieden sich bei früheren Versionssprüngen. Öffnet man nun alte Pläne mit neuen Bibliotheken, werden oft die Einsetzpunkte geändert, die Farben stimmen nicht mehnr, Materialien sind nicht da, Linienarten sind geändert, Schraffuren schauen ganz anders aus.
Ich will dann natürlich bestimmte Elemente ändern.
ZB. Kamine.
Ich öffne also die Dialogbox "Suchen und Aktivieren", stelle mir die Kriterien ein, die ich erwischen will, und aktiviere mir mit ALT+Click auf einen Kamin dann mit "+" alle jend, welche dem Kriterium entsprechen.
Dann ändere ich in der Werkzeugdialogbox einen Parameter global für alle Kamine - zB. die Stiftfarbe - und oh Wunder, eines der Kamin-Objekte hat einen anderen Parameternamen und geht mit der Aktion nicht mit. ARGERLICH (Die Kamine sind nur so ein Beispiel...)

Deshalb sollten alle ähnlichen Objekte in sich sozusagen gleiche (über Versionsgrenzen hinweg) Parameternamen verwenden.

In den Brandschutzsymbolen etwa verstellt man die dargestellte Größe zT mit A und B. Einzelne Dinger aber verstellen sich in der Größe jedoch nur mit der Schriftgröße.

Ich stell mir vor, daß ein GDL-Programmierer in einer öffentlichen von Graphisoft verwalteten Datenbank Einsicht nehmen kann. Er sucht sich die Klasse seines neuen Objektes, schaut sich dort die Namensregeln an, und programmiert mit diesen los. Sollte nun eine weitere Namensklasse oder Regel nötig sein, sollte er diese dort eintragen können. (diese sollte dann von Graphisoft geprüft werden - nur als GS-Prüfvermerk)

Dies würde in den meisten Fällen reichen.
Natürlich kann man in Archicad bestehende Objekte öffnen und nachschauen was Graphisoft da so gezimmert hat, aber so einem richtigen Standard scheint das auch nicht zu folgen und ist ein wenig aufwendig.

Außerdem wäre es gut, für wiederverwendbare GDL-Teilchen eine Doku zu erhalten. - ZB. Türblätter - welche Parameter übergeben werden usw.
AC5.5-AC27EduAut, PC-Win10, MacbookAirM1, MacbookM1Max, Win-I7+Nvidia
Bernhard Binder
Graphisoft Partner
Graphisoft Partner
</font><blockquote><font size="1" face="Verdana, Helvetica, sans-serif">Zitat:</font><hr /><font size="2" face="Verdana, Helvetica, sans-serif">Original erstellt von Heimo:
...Öffnet man nun alte Pläne mit neuen Bibliotheken...Das sollte man tunlichst vermeiden. Vor allem, sind die Bibliotheksnamen in den neueren Versionen schon geändert.

Trotzdem wäre eine Namenskovention für Parameter natürlich sinnvoll! Eine wirklich gute Anwendung wären zB Fensteränderungen bei denen die Größen erhalten bleiben (sollte IMO schon jetzt möglich sein, ist's aber nicht).

Die Sache mit den Einsetzpunkten ist allerdings auch mit so einer Konvention nicht gelöst. Es müsste die Vorschrift geben, dass der Nullpunkt zB immer links unten ist. Das macht aber bei manchen Objekten (zB Fenster u. Türen) keinen Sinn. Außerdem hat ja jeder Entwickler seine eigene Vorstellung davon wo sein Objekt beginnt.

Übrigens: selbst wenn der Einsetzpunkt eines Objektes immer gleich ist, kann das (auch schon bei geringen) Grössenänderungen ungeschickte Auswirkungen haben.
AC4.5-AC27 AUT, GER, INT
www.a-null.com
Anonymous
Nicht anwendbar
Diese "Konvention" gibt es bereits, allerdings nur innerhalb der GS-Entwicklerseiten. Ich glaube, GDL-Technology hat mal etwas darüber veröffentlicht.
http://www.gdltechnology.de/