ResourceDictionaries verschachteln

Bei meinem Projekt wird es sehr viele Templates und Styles geben.
Die Styles basieren teilweise auf andere Styles. D.h. es gibt ein Basis Style und spezialisierte Styles.
Deshalb würde ich gerne mehrere ResourceDictionary nutzen.
Dazu kommt, dass es sich dabei um eine DLL mit UserControls handelt.

Damit die spezialisierten Styles das Basis Style kennen, muss ich in dieser Datei die Basis Style Datei als Merged Dictionary angeben.

Dieses vorgehen, finde ich nicht so der Hit. Ich hätte gerne ein Dictionary das die Basis Style Files "inkludieren" und diese die Spezialisierungen.

Nun müsste ich zwar noch immer in jedem UserControl noch ein Dictionary inkludieren, aber das wäre noch ok.

Selbst wenn ich alle Spezialisierungen inkludiere, kommt es zu dem Problem.
Der "Designer" toleriert es zwar, aber zur Laufzeit kommt ein Fehler der aussagt, dass das Basis Style nicht gefunden wurde.

Wie habt ihr bereits sowas realisiert, was sind eure Ideen oder gibt es dafür ein bekannte Strategie wie man damit gut umgehen kann?

Ist nicht wirklich schwierig zu erledigen.

Erstelle dir ein Resource Dictionary, welches deine Basisstyles/-templates enthält. Die anderen Resource Dictionaries (mit Spezialisierungen) verweisen nun auf dieses Basis Dictionary, d.h. binden dieses in sich selbst ein. Das kann so erledigt werden:

Im spezialisierten Resource Dictionary einfach folgendes Markup verwenden (Shared.xaml ist das Basis Dictionary):

<ResourceDictionary.MergedDictionaries>
    <ResourceDictionary Source="Shared.xaml" />
</ResourceDictionary.MergedDictionaries>

Genau so habe ich es auch umgesetzt. Nur leider kommt es da, zu dem oben beschriebenen Fehler.

Ich beschreibe das Problem noch etwas anders.

Wenn ich alle Basisstyles inkl. Spezialisierungen in eine Datei schreibe, brauche ich nur diese Datei "inkludieren".

Sobald ich diese Dateien auslagere, muss die Datei mit den spezialisierten Styles/Templates die Datei in Richtung Basisklasse inkludieren.

Das bedeutet, ich kann nur eine "extrem" Spezialisierung inkludieren. Ansonsten würden die Basisklassen mehrfach durch die spezialisierenden Dateien inkludiert.

Auch wenn es funktioniert, wäre es keine gute Lösung.

Ah, hab überlesen, dass du bereits geschrieben hast, wie genau du es machst.

Also, in meinen Anwendungen wurde das so gelöst:

1. Genau so wie ich es gepostet habe bzw. wie du es anscheinend auch machst
2. Die Ressourcen werden in meinen Anwendungen global eingebunden, d.h. in der App.xaml.

Damit habe ich grundsätzlich überhaupt keine Probleme. Wenn ein Control einen speziellen Style besitzen soll, dann wird dieser explizit zugewiesen.

Eine App.xaml habe ich ja leider nicht (DLL) und bringt bei den Controls auch nichts.
Bei den Styles werden selbst die "primitiven" Controls wie z.B. Button oder Labels angesprochen.

Wenn man hört wie toll, WPF ist, wird oft gesagt:

"Man kann Styles definieren und dafür sorgen, dass alles gleich aussieht"

So einfach ist es aber nicht, dies ist nur die halbe Wahrheit. Wieso gibt es dafür keine "globale" Lösung für eine komplette DLL.

Wäre es nicht schön, für ein Namespace ressourcen hinterlegen zu können 🙂
Wenn dazu noch die Funktionaliät von partiellen XAML Files existieren würde, wären meine Probleme gelöst.

Und genau zu diesem Zeitpunkt, wäre die Aussage "Man kann Styles definieren und dafür sorgen, dass alles gleich aussieht" für mich auch wahr.

Wieso kann man Styles nicht genauso wie Klassen betrachten. Somit könnte man die Styles ohne Probleme einbinden und auch viel kompfortabler davon ableiten.

Für mich ist die Sache ein unnötiger riesen Verwaltungsaufwand und ist auch für eine Erweiterbarkeit nicht sonderlich hilfreich.

Eine App.xaml habe ich ja leider nicht (DLL) und bringt bei den Controls auch nichts.
Bei den Styles werden selbst die "primitiven" Controls wie z.B. Button oder Labels angesprochen.

Wenn man hört wie toll, WPF ist, wird oft gesagt:

"Man kann Styles definieren und dafür sorgen, dass alles gleich aussieht"

So einfach ist es aber nicht, dies ist nur die halbe Wahrheit. Wieso gibt es dafür keine "globale" Lösung für eine komplette DLL.

Geht doch. Schon wenn du eine Custom Control Library anlegst, wird auch ein Themes-Ordner mit angelegt. Darüber kannst du das Aussehen für alle Elemente aus deiner DLL ja steuern. Wenn du dies nun flexibel gestaltest, kannst du es so machen, dass bei einer Definition auf Anwendungs-Ebene deine Controls angepasst werden.

Was ich NICHT wollen würde ist, dass ich eine Control Library einbindet und DIESE definiert wie meine Buttons auszusehen haben. Kontraproduktiv. Ich möchte eine Controls Library einbinden, die mit einem Default-Aussehen kommt und ich ICH entsprechend anpassen kann.

Das ist auch Sinn und Zweck einer derartigen Library.

Wäre es nicht schön, für ein Namespace ressourcen hinterlegen zu können 🙂
Wenn dazu noch die Funktionaliät von partiellen XAML Files existieren würde, wären meine Probleme gelöst.

Damit wären keine Pobleme gelöst:

1. In einer Assembly können sich mehrere und unterschiedliche Namespaces befinden
2. Ein Namespace kann sich über mehrere Assemblies hinwegziehen

Dadurch wäre es äußerst sinnlos, Ressourcen auf Namespace-Ebene zu vergeben, zumal ein Namespace nur eine logische Kategorisierung ist und nichts weiter.

Und genau zu diesem Zeitpunkt, wäre die Aussage "Man kann Styles definieren und dafür sorgen, dass alles gleich aussieht" für mich auch wahr.

Kann man dann. Aber du sattelst hier das Pferd von der falschen Seite auf.

Wieso kann man Styles nicht genauso wie Klassen betrachten. Somit könnte man die Styles ohne Probleme einbinden und auch viel kompfortabler davon ableiten.

Styles können ja vererbt werden.

Für mich ist die Sache ein unnötiger riesen Verwaltungsaufwand und ist auch für eine Erweiterbarkeit nicht sonderlich hilfreich.

Sehe ich nicht so. Mit Hilfe der Styles ist es erst überhaupt möglich, Controls anders zu gestalten. Und das unabhängig von dem implementierten Code. Dass jedoch nicht alles über Styles abgedeckt werden kann sollte auch klar sein. Imho ist es eine Gestaltungshilfe und weniger ein Implementierungsfeature.

Ok meine Architektur sieht folgendermassen aus. Ich habe eine Windows.Form Anwendung und eine DLL mit meinen Klassen.

Da ich aber die WPF Techniken nutzen möchte, habe ich eine 3tes Projekt erstellt, in dem die WPF Controls enthalten sind.

Das Windows Form hat bisher immer UserControls in dem Form ausgetauscht. Damit ich nun WPF Controls einbinden kann, enthalten die UserControls nur noch die Logik und über ein ElementHost wird das WPF Control dargestellt.

Ich sehe es theoretisch genauso, dass die WPF Controls default-Aussehen haben.

Nur wie kann ich über meine Anwendung definieren wie die Styles von den Controls sind. Das Problem ist, dass auf dem WPF Control verschiedene Controls vorhanden sein können, die auch wiederrum WPF Controls beinhalten usw.

Wie kann sowas sauber realisiert werden?

EDIT:
Ok nehmen wir an ich mappe die Styles von den Untercontrols auf dem WPF Controls auf public Properties. Dann hätte ich noch immer das Problem, das ich von einer Windows.Form Anwendung auf kein ResourceDictionary zugreifen kann. Erstellen kann ich dies ja leider dort auch nicht.