Objekte verschiedener Kindklassen vergleichen

(27.06.2019 12:46 )seuk schrieb:  Damit fing das Übel an

Sehe ich genauso.

Ich sag dir kurz, wie mein Settingseditor aussieht:

• Grob gesehen eine FGV
• Am Bildschirm (also FP) gibt es idealerweise einen Cluster, in Zahl: 1, der idealerweise alle Settingsparameter enthält.
• Eine Referenz auf dieses Element (Cluster) bekommt die FGV. Sie kann also auf diesen Cluster zugreifen.
• 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 als interne Daten in einem Schieberegister die Settingsparameter, die im Cluster stehen. Hinweis: Trennung Daten vom Frontpanel.
• Die FGV wird über einem Enumerator gesteuert. Das entspricht dem Aufruf einer Methode.
• Daten gelangen per Variant in die FGV.
• Die FGV hat einen(1) Ausgang. Das sind die Settingsparameter.
• 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.
• 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.
  

Ich gehe davon aus, du verstehst, was ich meine und wie es funktioniert.

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 Frage:
Jetzt fragst du nach dem Problem: Unterschied des Typs der Settingsparameter in den verschiedenen Modulen. Die Intension deiner Frage ist ja: Nach Möglichkeit ein Modul ("Settingsmodul") verwenden, das alle Settings-Typen kann - wobei keine Änderung am Settings-Modul gemacht werden soll.

Meine Antwort:
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.