Hallo kartomac,
es geht hier nicht darum für alles neue oder zusätzliche Schalter festzulegen. Sondern um
A) Das Vereinheitlichen von Einstellmöglichkeiten und
B) Um das Erleichtern/Motivieren diese Technik in eigenen Objekten einzusetzen.
Wie schon mehrfach erwähnt: Das Makroobjekt kann nur die Schalter (nur für GDL-Objekte!) zur Verfügung stellen. Die Abfrage und Reaktion auf diese Einstellungen muss in die Objekte selbst einprogrammiert werden. Im Prinzip wie Schalter mit Kabelpeitschen. Anschließen muss sie jemand anderes.
Was spricht für die globalen Schalter:
- Ich kann zentral für eine Vielzahl von Objekten eine Einstellung treffen und diese damit steuern.
- Ich kann Varianten sehr schnell erzeugen.
- Ich kann globale Informationen für Objekte liefern, die in GDL sonst nicht abrufbar sind.
Was spricht dagegen:
- Ich habe einen weiteren Schalter, einen weiteren Dialog, wo sich eine gesuchte Einstellung verbergen kann
- Ich muss einen zusätzlichen Dialog aufsuchen, um Einstellungen vorzunehmen
- Ich kann ggf. keine individuellen Einstellungen mehr vornehmen.
GS bietet uns hiermit eine Technik, die viel Potential bietet. Aber auch zu unzähligen Einstellungsdialogen führen kann. Jedes Objekt, das diese Technik nutzen will muss einen Eintrag in den Modelleinstellungen anlegen. Dies tut es mit je einem derartigen Makroobjekt. Wenn im Lauf der Jahre sagen wir mal in deiner Bibliothek 10 Objekte sind, die das nutzen wollen, hast du schlimmstenfalls 10 zusätzliche Einstellungsabschnitte in deinen Modelleinstellungen. Womöglich mit thematisch gleichen oder identischen Schaltern. Genau das will ich mit diesem Objekt vermeiden.
Z.B. ist es nicht möglich den Indexwert der festen oder leeren Schraffur abzurufen. Kennst du den Namen nicht - und dieser ist nich festgelegt - musst du im Skript "raten" oder über einen Parameter abfragen. Kann ich an zentraler Stelle dies für das Projekt oder die Projektansicht einstellen, macht das mein "Leben" als Programmierer leichter und den Anwender schützt das vor Fehlfunktion oder redundanter Eingabe.
Gerade heute habe ich für eine Serie von Visualisierungen in einer Einstellung einen aufhellenden Lichtspot benötigt. Dazu habe ich das Allgemeinlicht-Objekt so umprogrammiert, dass es auf die Lichtschalter in den Modelleinstellungen reagiert. So konnte ich sehr schnell in der einen Visualisierung das Licht an- und in der anderen abschalten. Hätte ich das über verschiedene Ebenen gemacht, hätte ich nicht an zentraler Stelle einen Überblick über die Beleuchtungssituation und hätte außerdem einen zusätzlichen Layer und ein zusätzliches Ausschnittset erzeugen müssen. Nur für eine Variante, die vielleicht nachher verworfen wird.
Jochen hat z.B. Fenster umprogrammiert, die auf Fenstermaterialien aus den Modelleinstellungen reagieren können. So kann er über 4 zentrale Schalter beliebige Kombinationen der Fensterrahmen- und Flügelmaterialien erzeugen. Sowas geht schon gar nicht über Ebenen oder andere Bordmittel.
Im Int. Forum benötigte ein Programmierer die Differenzierung zwischen Schnittfenster und Ansichtsfenster. Das ist in GDL nicht abfragbar. Die Erscheinung des Objektes kann für beide Fenster nicht unterschiedlich programmiert werden. Mit einer Abfrage der Modelleinstellungen (Plantyp) geht das sehr wohl.
Zur Entkräftung meines letzten Gegenargumentes oben: Die Objekte sollten unbedingt eine Option enthalten, ob sie auf die globalen Modelleinstellungen reagieren oder nicht. Damit nicht die Probleme wie bei den Türaufschlagslinien und den den Öffnungslinien in der 13er Bib entstehen. Das ist aber Sache der Objektprogrammierer und nicht ein grundlegendes der verwendeten Technik.
In diesem allgemeinen Objekt sollen auch nicht unzählige Schalter aufgenommen werden. So habe ich für Jochens Objekte auch nicht globale Schalter für Rahmen- und Flügelmaterialien aufgenommen, sondern vier allgemein bezeichnete Materialien für Fenster. Im Objekt selbst und dann durch den Anwender kann entschieden werden, woher die Materialdefinition stammt: Objektmaterial oder globales Material 1,2,3 oder 4. Ob sie dann für Rahmen, Flügel oder Füllmaterialien oder Fensterbänke verwendet wird ist Sache des Anwenders (und der Optionen des Objektes natürlich).
All das KANN - MUSS aber nicht. Das entscheidet zunächst der Programmierer, ob er es vorsieht und dann der Anwender ober er es verwendet.
Einige globale Einstellungen habe ich ergänzt, die GS bisher einfach an anderer Stelle nicht liefert: Z.B. Planungskontext und Plantyp. Einen zentralen Schalter zur Anzeige von Hilskonstruktionen (innerhalb von Objekten) oder die differenzierte Anzeige von Markerinhalten.
Einige Parameter sollten daher so umfassend wie möglich erfasst sein. Z.B. eben der Kontext, weswegen ich hier um euren Input gebeten habe.
Jetzt klarer?