Interface- und Klassenstruktur für entkoppelte GUI und Anwendungslogik

[Aviator]

Naja es geht darum, dass für unterschiedliche Geräte unterschiedliche Werte abgerufen werden müssen. Diese Werte sollen aber auch anzeigbar und editierbar sein. Wenn aber nur die DLL selbst weiß, welche Werte vom Geräte abgerufen werden müssen, dann kann die GUI nichts anzeigen weil die Felder ja nicht existieren.

Also muss die DLL im Prinzip der GUI mitteilen, welche Felder vorhanden sein müssen und welche Werte diese haben.

Mit dem Ansatz den Ghostwalker mir geliefert hat, kann ich denke ich auch schon etwas anfangen. Zumindest versuche ich es mal.

Zitat von freimatz:

Ich gebe zu, dass ich das Problem kaum verstanden habe. Allerdings kann ich sagen dass bei uns nahezu alle Klassen auch ein Interface haben und Kontrakt und Implementierung zu trennen (und Referenzzählung zu haben).

Habt ihr denn auch eine GUI die sich abhängig von irgendwelchen Werten anpassen muss? Also neue Felder erstellen usw.? Das würde mich dann interessieren. Wie sieht so etwas bei euch aus?

Zitat von stahli:

Vielleicht hilft folgende Überlegung noch etwas weiter:

Die Geräte könnten auch Anweisungen für den Formularaufbau mitschicken (Edit1, an Position X/Y, gebunden an Wert Z; Button1, an Position X/Y, Beschriftung=OK, Action=SaveData)

Das wäre dann prinzipiell das, was Ghostwalker auch schon vorgeschlagen hatte. In die Richtung ging beim erster Gedanke auch schon, nur habe ich den im Ausgangspost nicht beschrieben um nicht irgendjemandem Worte in den Mund zu legen.