gemeinsam Konstanten in verschiedenen VIs

Hallo,

Zitat:Bei der genauen "Textanalyse" deines Beitrages komme ich zu dem Schluss, dass Du der Manie verfallen bist, GBs zu vermeiden und grundsätzlich FGVs zu verwenden. Diese Krankheit kommt davon, dass Du zu viel hier im Forum gelesen hast, wo diese Auffassung gepflegt wird. Lass Dich davon nicht anstecken!

Da muss ich doch glatt einsteigen!

Im Ernst:
Ich befürworte FGVs für solche Anwendungen, weil:
- ich zusammengehörende Einstellungen/"Konstanten" bündeln kann
- ich in der FGV gleich noch die passende (!) Lade-/Speicherroutine unterbringen kann, ohne dafür andere VIs pflegen zu müssen
- ich die FGV in mehreren Projekten verwenden kann, ohne mir Gedanken über die enthaltenen Größen zu machen

Beispiel:
Wir haben mehrere Prüfstände, die recht ähnliche Software nutzen: Hardware-Treiber unterscheiden sich, aber Anzeige/Logging/Setup/usw. sind identisch. Alle allgemeinen Einstellungen (Prüfstandskennung, Pfade zum Laden und Speichern von Dateien, etc.) landen in einer FGV. Ein Aufruf der FGV mit dem Parameter "load settings" lädt die zuletzt genutzten Einstellungen aus einer INI-Datei, ein entsprechender Aufruf der FGV am Programmende speichert die Settings. Vor dem Start der Messung darf der User nochmal die Settings überprüfen und ggfs. abändern, danach können alle Programmteile die (dann statischen) Settings nutzen. Die FGV wurde einmal entwickelt/getestet und nun auf allen unseren Prüfständen genutzt...

Diese Kapselung und Wiederverwendbarkeit ist es, die mich immer wieder dazu treibt, FGVs zu empfehlen...

D.h. nicht, dass ich keine globalen Variablen nutze - aber fast nur in dem recht klein abgesteckten Rahmen der "einmaligen" Nutzung ("nur ein Projekt"/"nur ein spezieller HW-Treiber mit verteilten VI-Aufrufen"). Und bei anderen Anforderungen mag man auch daran denken, LVOOP zu nutzen, um noch mehr oder viele unterschiedliche Daten in einem Objekt (mit entsprechenden Eigenschaften/Methoden) zu bündeln...