Objekte verschiedener Kindklassen vergleichen

Okay, bleiben wir kurz bei dem was ich schon habe. Das läuft gänzlich ohne OOP und ich wollte versuchen es mit OOP zu optimieren.

Ich habe derzeit folgendes Konstrukt:

Modul A hat einen TypeDef Cluster "Modul A Settings" und beinhaltet n Werte verschiedener Typen
Modul B hat einen TypeDef Cluster "Modul B Settings" und beinhaltet n Werte verschiedener Typen

Der Settingseditor hat einen TypeDef Cluster "Settings" in dem die beiden Cluster der zwei Module sind. Dieser große Cluster mit den Settings aller Modulen wird mit Flattern to XML in eine Datei geschrieben und bei Programmstart von da gelesen. Der Settingseditor ist ein QMH und besitzt auf dem FP Bedienelemente vom Typ "Modul A Settings" und "Modul B Settings".

Nun ändert der Anwender an den Bedienelementen etwas und drückt

• OK: Die Bedienelemente senden ihre Daten in den Cluster "Settings". Jetzt ist das ShiftRegister des QMH aktuell und er kommuniziert jeweils einen Cluster an ein Modul.
• Abbrechen: Die noch nicht aktualisierten Werte des Clusters "Settings" aus dem Shift Register werden in lokale Variablen der Bedienelemente geschickt. Ergebnis: Das FP zeigt wieder die ursprünglichen Werte an
  

Nun wollte ich erreichen, dass nur geänderte Werte an die Module kommuniziert werden und nicht die ganzen Cluster. Damit fing das Übel an :-)

(27.06.2019 11:48 )th13 schrieb:  Wenn du eine Referenz auf den Cluster hast, kannst du Mittels der Controls-Eigenschaft alle Elemente des Clusters in einer Schleife durchgehen.

Und genau das war mein erster Versuch: Ich vergleiche zwei Cluster und bekomme ein Bool-Array. In einer Forschleife kann ich mit der Referenz auf Cluster -> Controls() an Label.Text kommen und muss anschließend eine CaseStructure verwenden, um darin das richtige VI aufzurufen, welches genau für die Kommunikation dieser Wertänderung zuständig ist. Wenn ich also eine Beschriftung ändere, muss ich den Case anpassen. Bei Erweiterungen muss ich einen Case hinzufügen. Das wollte ich generischer gestalten. Puh, weit ausgeholt, aber nun ist mein Problem vermutlich viel deutlicher, auch wenn es mit der Überschrift kaum noch etwas zu tun hat.

(27.06.2019 11:45 )IchSelbst schrieb:  1. Zuerst bekommt das Modul von irgendwo her ("Herkunfsmodul") eine bestimmte Anzahl von Datenwerten, womöglich zusammengefasst als Cluster/Struct. Diese Daten sind dort, wo sie herkommen, z.B. Einstellparameter ("Settings")

Korrekt, siehe oben: Mein Settingseditor ist in der Hierarchie meiner Module ganz unten, die GUI ganz oben, ModulA und ModulB dazwischen. Insofern ist er selbst das Herkunftsmodul der Settings für die anderen Module.

(27.06.2019 11:45 )IchSelbst schrieb:  2. Diese Daten sollen angezeigt werden und vom Anwender geändert werden können: "SettingsEditor".

korrekt

(27.06.2019 11:45 )IchSelbst schrieb:  3. Sobald der Anwender sein OK für die geänderten Datenwerte gibt, sollen diese oder auch der ganze neue Datensatz zurück an das Herkunftsmodul.

korrekt

(27.06.2019 11:45 )IchSelbst schrieb:  4. Der Selbstzweck deines Programmmoduls ist also die Anzeige und Eingabe von Daten.

korrekt

(27.06.2019 11:45 )IchSelbst schrieb:  So grob wie das hier steht, ist das ja ohne Typdefinition der Daten. Das geht aber nicht. Fazit: Es werden nicht die Datenwerte übergeben, sondern tatsächlich Datenwerte samt deren Typdefinition. Sowas ist möglich ("Laufzeit-Typ-Information"? RTTI?). Ein Variant z.B. kann das. Und eine Referenz auf Cluster auch. XML-Files auch. Text-basierte Sprachen auch. Das Problem ist, dass das Modul typ-abhängige Eingabeelemente braucht.

Wie hast du das Problem der typ-abhängigen Eingabe gelöst? Siehst du hier überhaupt ein Problem?

In der lauffähigen Version habe ich das über die TypeDef Cluster der Module realisiert. Doch um das ganze flexibler zu gestalten, wollte ich mich davon verabschieden. Ich möchte die GUI möglichst abkoppeln, damit z.B. nicht alle Settings an einer Stelle im Programm vorgenommen werden müssen, um Settings auszublenden, um Abstraktion für den Anwender einzubauen (z.B. TemperaturRange: "High" statt 100-250°C) etc.

Möglicherweise wird auch das noch zu Problemen führen. Ich hatte mir vorgestellt, dass der Settingseditor zukünftig vom GUI Modul eine Nachricht erhält und dieser kommuniziert die Werteänderung dann weiter an die Module. Die GUI sollte also "dumm" bleiben dürfen, damit die Logik "welche Werteänderung muss kommunizert werden?" im Settingseditor bleibt und nicht mehrfach implementiert werden muss. Ich dachte ich gebe jeglicher GUI also einfach auch den Zugriff auf alle Settings, in der GUI werden Änderungen vorgenommen und die kompletten Settings an den Settingseditor geschickt, der dann wie beschrieben weiter macht...

(27.06.2019 11:45 )IchSelbst schrieb:  Das Schöne an so Sachen wie .IsEqual oder .ToString, dass die ja in der objektorientierten Sprache systemimmanent im Datenobjekt sind. D.h. der Programmierer muss sich hier um nichts kümmern, muss sich also nicht um die Typverträglichkeit kümmern. In LabVIEW müsstest du eine Funktionalität generieren, die in objekt-orientierten System bereits integriert ist. Siehst du das auch so?

Ich bin mir sicher, ob ich dich richtig verstehe. Ich kann zwar die LV Funktion "= Equal?" auf Objekte anwenden, doch wollte ich das nicht. Ich dachte ich schreibe eine eigene Funktion, die beispielsweise bei TemperatureRange die Min und Max Werte miteinander vergleicht und true zurück gibt, wenn dies der Fall ist. Ob das zweite Objekt dann eine Kopie oder Referenz ist, wäre mir gleich, da ich nur die Werte vergleichen wollte.