Objekte verschiedener Kindklassen vergleichen

Hallo GerdW,

(27.06.2019 10:32 )GerdW schrieb:  

Zitat:In dem Moment habe ich zwei Arrays von AbstractSettings, eines enthält die aktuellen Daten, ein anderes die neuen.

Das verstehe ich nicht: es gehen Daten in den Editor rein und es kommen (evtl. angepasste) Daten heraus (DATFLOW). Wieso hast du jetzt zweifach Daten?

Änderungen sollen erst propagiert werden, wenn der Anwender auf OK klickt - drückt er auf Abbrechen, müssen die bisherigen Einstellungen beibehalten werden.

Dazu mein Ansatz
- die Änderungen an den Bedienelementen gehen die neuen Werte sofort per Event Struktur in eine Kopie des Arrays
- bei Knopfdruck OK: Array ALT mit Array NEU vergleichen --> nur Änderungen an einzelnen Bedienelementen kommunizieren
- bei Knopfdruck Abbrechen: Array Alt auslesen und Bedienelemente auf dessen Werte setzen.

Ich bin aber offen für schlauere Lösungsmöglichkeiten. Die Idee mit dem Flag werde ich mal durchdenken. Ich glaube ich habe mein Klassendesign noch nicht schlau gelöst!

Konkrete Settings Klassen wären z.B. TemperatureRange und TemperatureUnit

An der oben genannten Stelle des Settings Editor wäre es schön all diese Settings Klassen in einem Array durchlaufen zu können, um sowas wie if isEqual() then sendData() machen zu können. Damit hier keine Änderungen bei Erweiterungen nötig werden würden.

Andererseits muss ich ja auch irgendwo die konkreten Werte in die Settingsklassen bekommen und wieder auslesen können. Die Getter und Setter für die konkreten Settingsklassen wären unproblematisch (z.B. TemperatureRange.getMin() ). Aber woher weiß ich denn, an welcher Stelle des Arrays welche Settingsklasse ist?
Dies würde dafür sprechen alle Settingsklassen in einen Cluster zu packen. Hmm, muss ich hier einen Tod sterben, oder bekomme ich irgendwie die beiden Vorteile von Cluster und Arrays vereint? Ich wollte hier eigentlich nicht so stark vom Thema abdriften. Hab mich nun schon mit Variant Lookup Tables, Current Values Tables und den neuen MAP und SET Datenstrukturen von LV2019 eingelesen. Ich dachte mit Klassen könnte ich dem Problem besser begegnen, aber vielleicht liegt mein Problem auch ganz woanders...? Ich möchte Typsicherheit schon bei Edittime erreichen, damit sind Variants raus. Zudem möchte ich bei Erweiterungen eine zentrale Definition, wie eben ne TypeDef oder Klasse, anpassen und dann so wenig wie möglich ändern, bzw. hinzufügen müssen.