Objekte verschiedener Kindklassen vergleichen

(27.06.2019 16:13 )seuk schrieb:  Wird da nun ein Variant, ein Cluster, oder ein TypeDefCluster übergeben?

Übergeben wird das, was die Methode verlangt. Wenn der ganze Settingsdatensatz in de FGV soll (Methode SetAllData), dann wird ein Cluster an den Variant-Eingang angehängt. Da die FGV den Typ des Datensatzes kennt, kann die Methode SetAllData mit dem Element VariantToData, das zum Konvertieren ja einen Typeingang hat, aus dem Variant die Daten wieder als Cluster herausholen. Verlangt die Methode z.B. nur einen Double (z.B. TempMin), kommt ein Double an den Eingang, der Typ Double an den VariantToData und schon ist ein einzelner Wert (nämlich TempMin) in die FGV gekommen (und die könnte den jetzt in den Settingsdatensatz schreiben ...)

Zitat:Kennst du eine Möglichkeit mit Variants Typsicherheit während der Edittime zu gewährleisten?

1. Was meinst du denn mit Edittime? Den Zeitpunkt, zu dem das Programm geschrieben wird? Also die Entwicklungszeit als Gegenteil von Runtime?
2. Wenn zur Entwicklungszeit: Du weißt als Entwickler doch, welchen Typ du anschließt - und welchen nicht. Warum dann Typsicherheit gewährleisten? Das verstehe ich nicht: Wenn ein ganz bestimmter Typ am Variant anliegen soll, warum dann einen Variant nehmen? Dann kannst du doch gleich den Originaltyp übergeben?
3. Der Variant ist doch gerade dazu da, verschiedene Typen anschließen zu können.

Zitat:Ich bin mir nicht sicher, ob ich diesen ClustersaurusRex sehen möchte.

120 Parameter müssen nicht in einem Cluster liegen. Dafür hab ich ja idealerweise geschrieben. So ein FGV kann statt einem Cluster auch 20 Cluster verwalten. Jeder der Zwanzig würde dann auf einem Reiter eines TabControls liegen.

Zitat:Ich stelle mir eine Anwendung vor, bei dem es 120 Settings gibt und ein VI, welches davon genau 1 benötigt.

Wenn du 120 Parameter hast und nur einen brauchst, zeigt dann dein SettingsModul 120 Parameter an oder den einen? Woher weiß das Settingsmodul welcher der eine ist?

Zitat:Aber wenn ich von einer HW in einem DropDown auf eine andere HW wechsel, muss das Modul schon etwas mehr machen und sollte genau in einen Case hüpfen, der die nötigen Aufgaben abarbeitet.

Selbstverständlich kann meine FGV sowas: Einmal direkt mit einer speziellen Methode und der Übergabe dieses einen Wertes im Event-Case "SettingsCluster.HW-DropDown(ValueChange)". Außerdem geht das auch indirekt, indem in der Methode SetAllData der neue Wert HW-DropDown mit dem alten verglichen wird.

Zitat:ob ich da eine FGV oder ne Klasse nehme, dürfte ja keinen großen Unterschied machen.

Genau, deswegen heißen ja auch FGV "Klasse für kleine Leute" (Zitat von RolfK).

Zitat:Widerspricht sich das nicht mit der Trennung der Daten vom Frontpanel?

Nein. In 99% der Fälle schreibt die FGV die Daten per Referenz und Eigenschaftsknoten Value in diesen Cluster - nur damit der Anwender was sieht. Ausgelesen wird dieser Cluster nicht.

Zitat:Wie kannst du deine FGV testen und laufen lassen, ohne das ein FP dazu läuft?

Da läuft ja ein FP - das von der FGV. Da gibt es eigentlich nicht viel zu debuggen. Es kommen Daten herein, die gespeichert werden. Und Datenverarbeitung findet nicht in diesem VI statt, sondern in einem Unterprogramm ...

Zitat:Du hast für jedes Modul einen eigenen Settingseditor als FGV implementiert.

Wo liegt das Problem? Schließlich bin ich Programmierer ... An solch einem "SettingsEditor" ist nicht viel dran. Ein Cluster am FP des MainVI, ein Event-Case in der sowieso standardmäßig vorhandenen Ereignissequenz. Das reicht. Alles andere ist Benutzerfreundlichkeit.

Zitat:Aber dann gibt es keine Trennung zwischen den Settings und dem Modul.

Genau das ist Sinn und Zweck: Datenkapselung ...

Zitat:Wie gehst du mit Settings um, die Auswirkungen auf mehrere Module haben?

So einen Fall habe ich noch nicht gehabt. Die würden bei mir dann wohl ein eigenes Modul (einschließlich FGV) sein oder nur eine FGV namens S1. Die Module M1, M2, M3 hätten dann eigene FGVs Mx und wären berechtigt die Daten von S1 zu verwenden. Wie ein ValueChange dann an die Module Mx käme, müsste ich noch überlegen.

Zitat:Ich habe ein Modul für die GUI, eins für die Datenerfassung, eins für Logging und eben eins für die Settings dieser Applikation,

Ja, das hab ich auch so. Bei mir haben diese Module alle 5 maximal 50 Parameter. Von den FGVs im Hintergrund sieht der Anwender ja nichts. Der sieht nur ein TabControl mit vielen Reitern, auf denen alle Daten verteilt sind.



Wenn du 120 Parameter hast, was sieht denn der Anwender? Sieht der alle verfügbaren Parameter, praktisch am Stück, wenn auch über mehrere Reiter verteilt, so wie bei mir?


Was ich mir auch und gerade bei 120 Parametern vorstellen könnte, wäre eine "indizierte Eingabe": Der Anwender sieht zwei Eingabeelemente. Ein Pulldown (Ring) in dem alle Parameter mit Klartextbezeichnung aufgeführt sind. Dann sieht er rechts daneben ein Eingabefeld (Typ String, der kann alles). Der Anwender sucht sich aus dem Ring den Parameter, den er ändern will. Dann gibt er im Eingabefeld den neuen Wert ein. Mit diesem Verfahren bist du unabhängig von jedwedem Clustertyp. Du kannst für jeden Parameter im Ring einen standardisierten Datensatz definieren, der z.B. Quelle und Ziel des Parameterwertes enthält. Und den Typ des Parameters samt Wertebereich. etc. Dieses Verfahren wäre soweit abstrahierbar, dass Typ und Anzahl der Parameter egal wären. Hat nur einen Nachteil: Der Anwender muss diesem Eingabeverfahren zustimmen. Möglicherweise ist ein Zwischending möglich: Das würde auf einen standardisierten, komplexen Datentyp (Cluster) hinauslaufen z.B. "Sollwert mit Grenzen": Cluster aus 3 DBL.