Enthaltene Controls in einer WPF-UserControl

VolkerJuergen

Grünschnabel
Guten Tag alle miteinander.

Ich bin neu in diesem Forum und hoffe das ich hier die passenden Leute finde um Probleme/Lösungen zu diskutieren.

Nun zu meiner Frage:

Ich schreibe zur Zeit eine neue Oberfläche zur Bedienung von Maschinen. Die Oberfläche ist eine Windows-Form-Anwendung.
Zum Auslösen von manuellen Bewegungen gibt es sogennante Einrichtseiten. Dort sind Buttons zum anwählen der Bewegungen und Anzeigeelemente (zB. Textboxen) enthalten.

Geplant ist bis jetzt, das ein Nicht-Programmierer diese Einrichtseiten mit Expression Blend generiert und ich diese Usercontrol dann über den Elemethost im Hauptprogramm einbinde. Soweit auch kein Problem.

Da ich aber nicht weiß, welche bzw. wieviele Buttons , Textboxen etc. eingebunden werden muss ich das im Elementhost platzierten UserControl durchlaufen und schauen was für Controls eigentlich vorhanden sind.

Und da ist mein Problem, wie komme ich auf die Auflistung der Controls im WPF-UserControl ran damit ich diese durchlaufen kann?

Eine Lösung wäre eine Auswerten der Controls in der "Code Behind Datei" des UserControls. Das würde aber für mich bedeuten, das ich jede vom Grafiker erstellte Einrichtseite nochmals "nacharbeiten" müsste.

Hat vielleicht jemand eine Idee wie man das Problem elegant lösen könnte?

Vielen Dank schonmal im Vorraus.
 
Mal anders:
Was genau soll denn das UserControl an Arbeiten übernehmen? D.h. wofür genau musst du wissen, wieviele und welche Child-Elemente dieses hat?
 
Also im UserControl sind folgende Elemente enthalten:

Buttons die auf eine Globale Variable eine Nummer übergeben.
Textboxen welche je nach Zustand eines Bits die Anzeige ändert bzw. Integervariable anzeigt.

Es ist also nichts anderes als mehrere Seiten die mit Buttons und Anzeigeelementen gefüllt ist (deswegen auch der Elementhost um dynamisch mehrere Seiten anzuzeigen).

Hintergedanke war die Flexibilität der Oberfläche, da die Grundfunktionen (Datenbankanbindung, Kommunikation über OPC-Server etc) immer die Gleichen sind und sich eigentlich nur das grafische Übersichtsbild und eben diese "Einrichtseiten" ändert.

Habe mir folgende Vorgehensweise gedacht dabei:
1. Ich leite Steuerelemente ab und erweitere sie mit dem Property "Datenbereich", in dem beim Button die Nummer und bei den Textboxen das Bit konfiguriert wird.
2. Ein Designer nimmt sich dann Expression Blend und fügt die eigenen Steuerelemente ein und passt die Seite grafisch nach seinen Wünschen an.
3. In einem Konfigurationsdialog gibt man an welche WPF-Seiten man in der Oberfläche nutzen möchte welche ich dann beim Anzeigen der Seite dynamisch lade.
4. Ich durchlaufe das Programm und aktualisiere jedes Steuerelement aufgrund der im Property angegebenen Datenbereichs. Deswegen sollte ich wissen welche Controls überhaupt enthalten sind.


Das war bis jetzt mein Grundgedanke über das Zusammenspiel von der WinForm-Oberfläche mit den WPF-Komponenten.

Mir war die Option sympatisch das der Designer ein Designprogramm hat und nicht mit ihm unbekannten Windows Form Komponenten rumbasteln muss (vor allem da die grafische Designmöglichkeit doch eher beschränkt ist).

Ich hoffe ich habe bei der ganzen Sache nicht einen grundlegenden Denkansatz.
 
Um es ein wenig zu abstrahieren:
Ein Designer entwickelt eine XAML-Page, welche in einer WinForms-Anwendung gehostet wird. Diese XAML-Page soll dann in weiterer Folge Daten anzeigen, die von der WinForm-Anwendung an die jeweilig geladene XAML-Page übergeben und anzeigen soll.

Habe ich das jetzt so korrekt verstanden?
 
Genau, zusammengefasst passt das :) Aber wie gesagt, was genau in der XAML-Page enthalten ist weiß ich nicht.

Nach mehreren Tests und Versuchen habe ich mir schon überlegt ob ich nicht eine allgemeingültige "Code Behind" Datei anlege um über diese dann die Werte übergebe.
Ich hatte bis jetzt das Gefühl das ich in dieser Datei mehr Möglichkeiten habe als nachher in der Windows Form Anwendung.
 
Naja, du wirst vermutlich Objekte haben, die angezeigt werden. D.h. es gibt insgesamt zwei Möglichkeiten:

  1. Der Designer verwendet nur die Eigenschaften, welche deine Objekte zur Verfügung stellen. Dies können alle Properties sein, oder auch nur ein Subset davon.
  2. Der Designer kann auch zusätzliche Felder anlegen, welche über das Objekt nicht abgebildet werden. Da musst du dir ein Konzept überlegen, wie du die Daten dennoch gespeichert bekommst (Verwenden von Extensions, whatever).
 
Zurück