Objekte verschiedener Kindklassen vergleichen

Vielen Dank für deine ausführliche Antwort!

(27.06.2019 14:19 )IchSelbst schrieb:  Ich gehe davon aus, du verstehst, was ich meine und wie es funktioniert.

Sehr optimistisch, aber danke für das Vertrauen.

(27.06.2019 14:19 )IchSelbst schrieb:  

• Daten gelangen per Variant in die FGV.
• Bei einer Wertänderung wird der komplette Cluster an die FGV übergeben. Was die dann mit diesen Daten macht, ist beliebig. Ob sie zwei Settingssätze parallel führt oder nicht ist zweitrangig.
  

Wird da nun ein Variant, ein Cluster, oder ein TypeDefCluster übergeben?

Kennst du eine Möglichkeit mit Variants Typsicherheit während der Edittime zu gewährleisten? Variant Lookupt Tables sind ja sehr performant, aber es kommen halt Variants raus und ob am Variant To Data der richtige Datentyp angeschlossen war, seh ich erst zur Laufzeit - das erscheint mir doch ein sehr großer Nachteil.

(27.06.2019 14:19 )IchSelbst schrieb:  

• Am Bildschirm (also FP) gibt es idealerweise einen Cluster, in Zahl: 1, der idealerweise alle Settingsparameter enthält.
  

Ich bin mir nicht sicher, ob ich diesen ClustersaurusRex sehen möchte. Ich kann mir kaum vorstellen, wie der für einen Anwender gut zu bedienen ist, oder wie das FP von VIs aussehen, die davon einen Wert benötigen. Ich stelle mir eine Anwendung vor, bei dem es 120 Settings gibt und ein VI, welches davon genau 1 benötigt. Wie debuggt man das? Woher weiß man, welche Werte wo geändert werden?

(27.06.2019 14:19 )IchSelbst schrieb:  

• Wertänderungen von einzelnen Parametern geschehen immer über einen Value(Change) vom ganzen Cluster. Auch wenn das offensichtlich erheblich mehr Prozessorzeit kostet - das ist egal.
• Die FGV hat einen(1) Ausgang. Das sind die Settingsparameter.
  

Was die Performance angeht bin ich bei dir. Ich möchte kein Dictionary mit 360k Wörtern aufbauen und muss darin super schnell suchen können. In dem Fall ist mir Performance also auch nicht wichtig. Aber das Modul soll auf eine Werteänderung spezifisch reagieren können. Manchmal ist das nur ein Parameter, der sowieso schon an einem SubVI angeschlossen ist und sobald der geändert wurde, rechnet das SubVI halt anders. Dann ist es natürlich kein Problem. 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.

(27.06.2019 14:19 )IchSelbst schrieb:  

• Grob gesehen eine FGV
• Die FGV wird über einem Enumerator gesteuert. Das entspricht dem Aufruf einer Methode.
• Die FGV hat als interne Daten in einem Schieberegister die Settingsparameter, die im Cluster stehen. Hinweis: Trennung Daten vom Frontpanel.
  

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

(27.06.2019 14:19 )IchSelbst schrieb:  

• Eine Referenz auf dieses Element (Cluster) bekommt die FGV. Sie kann also auf diesen Cluster zugreifen.
  

Widerspricht sich das nicht mit der Trennung der Daten vom Frontpanel? Wie kannst du deine FGV testen und laufen lassen, ohne das ein FP dazu läuft? Dann hast du doch keine Referenz...? Wie implementierst du eine andere GUI für das gleiche Modul?

(27.06.2019 14:19 )IchSelbst schrieb:  

• Die FGV enthält standardisierte(!) Methoden, z.B. File-Schreiben/Lesen etc. Diesen Methoden, die den Typ Cluster an sich verlangen, ist der genaue Aufbau des Clusters egal.
  

Diese FGV kann man als einen Teil des Modules A (bzw. B etc) sehen. Die FGV ist also ein modul-internes Objekt. Alle Date, die in der FGV stehen, sind genau in dem Moment, indem sie in der FGV stehen, eben im Modul bekannt. => Ein Transfer ist nicht notwendig.

[...]
Deine Intension trifft genau meine: Ein Modul, das alles kann. Soll ohne Änderung, also nicht mit einer einzigen, wieder verwendbar sein. Problem ist, dass das tatsächlich sehr viele Probleme aufwirft. Daher habe ich meine FGV so standardisiert, dass bei der Implementation in ein anderes Modul tatsächlich nur minimale Anpassungen notwendig sind. Weil die wichtigsten Methoden (File-Schreiben/Lesen) Typ-unabhängig sind, geht das. Folgendes muss angepasst werden:

• Der Typ des Schieberegisters. Ganz einfach: "Ersetze durch" neuen Cluster.
• Der Typ des Eingangs und des Ausgangs der File-Schreiben/Lese-VIs. Ganz einfach: "Ersetze durch" neuen Cluster.
• Der Typ der Referenz auf das Anzeige/Bedienelement. Mit den neuesten LV-Versionen geht auch das endlich problemlos ...
• Sollte sich aus irgendeinem Grund der Cluster der Settings ändern, muss lediglich die Referenz auf den Cluser am FP geändert werden.
  

Der Aufwand für diese Anpassungen ist im Verhältnis zu den weiteren Arbeiten an einem Modul so gering, dass ich hier keine Notwendigkeit für einen eigenen Settingseditor sehe.

Jetzt bin ich aber doch baff. Du hast für jedes Modul einen eigenen Settingseditor als FGV implementiert. In dem Fall kann die Reaktion auf eine Werteänderung natürlich direkt in der FGV passieren. Aber dann gibt es keine Trennung zwischen den Settings und dem Modul. Wie gehst du mit Settings um, die Auswirkungen auf mehrere Module haben? In welchem Cluster / FGV stehen die dann? Zumindest wird ein Settingscluster dadurch, dass er nur für ein Modul zuständig ist kleiner.

Fraglich ist natürlich auch, was überhaupt ein Modul ist. 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, also aller Module. Damit hab ich auch nur ein XML File, welches die gesamte Anwendung konfiguriert.

Für heute mache ich Feierabend, aber ich werde nochmal darüber nachdenken, was für Vor- und Nachteile ein Settingseditor für die gesamte Anwendung im Vergleich zur Implementierung in jedem einzelnen Modul hat.

---

(27.06.2019 14:45 )IchSelbst schrieb:  Jawohl! Mir ist da sofort das programmatische Erstellen von Anzeige/Bedienelementen zur Laufzeit in den Sinn gekommen. Leider kennt LV sowas nicht.
...

Zitat:Ich möchte die GUI möglichst abkoppeln,

Sehr guter Wunsch. Den hab ich nämlich auch: Bei mir ist er alleine in der Trennung der Daten vom Frontpanel begründet. Das FP ist ein lästiges Übel, das man braucht, damit der Anwender was sieht und eingeben kann.
...

Zitat:Ich hatte mir vorgestellt, ...

Das klingt aber eher nach einen Diplomarbeit, als nach mal eben machen und im Forum Hilfe bekommen ...

Noch kurz zu deinem letzten Beitrag:

• Ich finde es Okay in der GUI für den Anwender ein weiteres Bedienelement manuell hinzufügen zu müssen, wenn ich eine neue Funktion implementiere, die solch eine Einstellungsmöglichkeit erfordert. Ggf. muss der Anwender diese aber auch nicht zu sehen bekommen.
• In meinem QMH in der GUI möchte ich dann nur einen EventCase dafür anlegen und ein VI reinwerfen, welches den Settingseditor informiert.
• Im Settingseditor benötige ich ebenfalls ein neues Case, welches diese Information empfängt.
• Ich muss natürlich bei der Anlage des neuen Settings festlegen, welchen Typ die neue Info hat, wie man überprüfen kann, ob die Info gleich ist (isEqual) und wie der Settingseditor die neue Info an ein anderes Modul übermitteln soll.
• Schließlich muss ich in den Modulen, die diese neue Info benötigen auch noch Cases anlegen, welche diese verarbeiten.
  

Ich denke allerdings, dass es eine Möglichkeit gibt, mit der das Speichern dieser neuer Info im Schieberegister des Settingseditor nicht erweitert muss. Das Speichern und Laden der XML-Datei muss ich so auch nicht anpassen.