Nabn'd

Wie ich sehe, ist der Content belegt.
Ist das nicht der Grund, ein ContentControl mit (mehr) Inhalt (Controls) zu befüllen?



Ist schon Mitternacht, was weiß ich denn um diese Uhrzeit?

c.u. Joshi

Das alles so in die Ressourcen auszulagern, ist etwas prekär und scheint hier wirklich etwas Zusammengewürfeltes aus diversem Code zu sein. Ich habe den XAML-Inhalt mal spaßhalber in einem leeren WPF-Projekt eingefügt, um zu sehen, was eigentlich auf dem Bildschirm – und vor allem wie – dargestellt wird. Normalerweise bleiben die Elemente Button, Label, TextBlock im Hauptcode und ausgelagert wird der Style oder Template, so wie in diesem Beispiel unten – man muss nicht immer alles komplizierter und sich dadurch das Leben unnötig schwer machen als es eh schon ist, wenn man auf einfacherem Wege etwas Vergleichbares oder gar Identisches erreichen kann. Was genau soll dieser Kalender denn so können oder sich ungewöhnlich verhalten, dass man das so verwringt machen muss? Was soll in dem Layout zur Laufzeit änderbar sein?

Morrison schrieb:

aber ich kann jetzt über ContentControl nicht auf die Eigenschaften der einzelnen Controls im Template zugreifen.

ja. das soll man ja auch garnet.
In Wpf hat man ein Viewmodel, und greift auf Eigenschaften des Viewmodels zu.
Ans Viewmodel gebunden ist dann ein in Xaml gecodetes View. Auf dessen Eigenschaften greift man nie zu.

---

Vielleicht will Joshi ja auch darauf hinaus, wenn er sagt, ein ContentControl.Content belegt man normal mit mehr Inhalt als mit einem String.
Nämlich da gehört ein Binding ans Viewmodel hinein, und für das Binding soll es in den Resourcen ein DataTemplate geben.

Aber ich weiss garnet, inwieweit dir der MVVM-Pattern bekannt ist...
Ohne den macht es nicht viel Sinn, Wpf zu programmieren...

Vielleicht hilft diese Information auch etwas weiter: es gibt außer dem Grid – der einem von Visual Studio als default immer in WPF vor die Nase geklatscht wird, bei dem Leute dann oft „hängenbleiben” und manchmal dann komische Dinge damit veranstalten, um etwas auf dem Bildschirm darzustellen – auch noch andere Panelelemente, die entweder genauso wie das Grid direkt an das Window angeknüpft oder auch fast beliebig untereinander kombiniert werden können. Die KontrollElemente und alles, was so da drin sich befindet, sind durchaus in der Lage, sich selbst auszurichten und mit vordefinierten Prozentangaben sogar die richtige Position und Breite anzunehmen, ohne explizit immer manuell die Reihen und Zeilen durchexerzieren und angeben zu müssen – so'ne Woche vom Kalender kann man damit bestimmt automatisch einfach so einblenden, vielleicht sogar einen ganzen Monat. Man muss sich allerdings etwas Zeit nehmen und ein wenig damit herumexperimentieren, bis man das gewünschte Puzzle findet und auch anwenden kann (es kann sein, dass ich was vergessen und es nicht erwähnt habe):

• Grid – jou, kennen wir ja schon
• UniformGrid – eine Sonderform von Grid
• StackPanel – wie der Name schon sagt, kann man hier etwas stapeln – sowohl horizontal als auch vertikal
• WrapPanel – ähnlich wie Stackpanel, nur dass hier Elemente umgeschlagen werden können
• DockPanel – zum Andocken links, rechts, oben und unten – damit kann man auch sehr schöne Kreationen in Verbindung mit z.B. Stackpanel auf dem Fenster schaffen
• Canvas – für absolute Pixelangaben auf dem Tisch genau das richtige Ding
  

Wenn nach dem Renovieren und Neutapezieren des eigenen Codes die eigenen Probleme nicht kleiner, sondern womöglich noch größer geworden sind und einem die MVVM-Doktrin nicht wirklich angenehm ist, kann man eine Anwendung auch komplett ohne diese Dogmatik programmieren, unabhängig davon, wie einfach oder komplex die Logik der Anwendung sein mag – ist leider kein Witz.

Im Gegensatz zu Gregor vermute ich die Probleme eher darin, dass hier MVVM nicht richtig angewendet wurde.

Aber ich weiss grad nicht, in welche Richtung gelaufen wird: Versuchst du, das Problem mit oder gegen MVVM zu lösen?

Weil bei gegen haltich mich besser zurück - hat ja kein Sinn, mehrere Lösungswege gleichzeitig zu beschreiten, die einander auch noch ausschliessen.

Morrison schrieb:

(...) Mit vb.net kenn ich mich ja bissl aus, aber WPF ist für mich Neuland..ich find WPF aber sehr interessant auf Grund des Binding-Verhaltens und der individuellen Gestaltung der Controls! (...)

Ja, ja, die Bindungen – wo man dann das Gefühl hat, dass quasi alles automatisch läuft oder laufen könnte, ohne dass man dafür die Logik tatsächlich bis ins Detail ausformulieren muss – können einen schon mal ganz schön locken, aber wenn man tatsächlich neu im Geschäft ist, wie man selbst schreibt, ist so ein Kalender – wie man sich ihn vorgestellt hat – möglicherweise etwas zu viel für den Anfang – eine klassische Überforderung. Man kann erstmal kleine Brötchen nach der MVVM-Doktrin backen lernen, am besten nur ein Brötchen ohne alles, und wenn dass klappt, kann man die Liste der Zutaten erweitern, die Öfen und deren Temperaturen vergrößern.

@Morrison Ich habe eine Mappe angehängt, ein CustomControl mit ResourceDictionary das ein Style mit Template mit ControlTemplate beinhaltet. So kannst du dann das Layout festlegen und weitere Controls in dem Control einbauen.

Ob man dafür auch MVVM anwenden kann/sollte bin ich mir noch nicht sicher, brauch noch ein bisschen um damit richtig klar zu kommen, da frage ich hier mal ganz frech @ErfinderDesRades. Wie würdest du Costum-Controls(nicht User-Controls) in WPF machen?

Ich habe einfach mal diverse Sachen ausprobiert, bin zig mal auf die Nase gefallen. Aber nun hab ich was, was schon mal funktioniert. Das ist nur zu Trainingszwecken, Das Control hat 2 Labels und 2 Buttons, Buttons für je Tag vor und Tag zurück, die beiden Labels zeigen das Datum in 2 verschiedenen Formaten an. Die Observable klasse spar ich mal aus, die implementiert nur INotifyPropertyChanged.
CalendarDay.cs

CalendarDay.xaml


Ab hier dann MVVM Pattern bei der Anwendung des Controls:
MainWIndow.xaml

Und noch das ViewModel:

Schau mal hier, vllt hilft die das sample weiter.


codeproject.com/Articles/39199…nth-view-Calendar-Updated

Morrison schrieb:

(...) Und das MVVM-Prinzip wollte ich schon einhalten (...)

Wer an die MVVM-Doktrin glaubt, sollte bereit sein, zu leiden und sich vor allem nach den Regeln dieser Glaubensansätze ausrichten, egal wie sinnvoll oder weniger sinnvoll sie sein mögen, sonst gibt es gleich einen Aufschrei der Pharisäer, die ihren Jüngern diese Lehre um jeden Preis so eintrichtern wollen, wie sie im Kanon ins Stein gemeißelt worden ist ; ) Aber Spaß beiseite, wie ich schon sagte, ich persönlich würde mich der Sache langsam annähern, erstmal ein Brötchen ohne alles (also nix gleich mit saftigem Schinken oder so) in einem kleinen Backofen kreieren, um dann mit Analogien und weiteren, neuen Elementen aus dem MVVM-Pool das ganze zu erweitern oder nur üben und dadurch verstehen lernen, um danach das Eigentliche als ein neues Projekt auf die Beine stellen, denn wenn man es umgekehrt macht, wird man stolpern – solche Enttäuschungen können dann dazu führen, das man WPF ganz schmeißt, was schade wäre, denn man kann da auch sehr schön ohne diese ganze MVVM-Dogmatik programmieren – WPF ist für alle da. Wenn man den Code von jemandem quasi fertig bekommt, wird das einem in so einer Situation nur kurzfristig, aber nicht dauerhaft helfen, weil eben die Nachhaltigkeit fehlt; aber wie gesagt, ist nur meine persönliche Meinung – jeder darf das tun, was er für richtig hält, das gilt auch für die Art und Weise wie man z.B. in WPF, WinForms oder sonst wo programmiert. Wenn man wirklich programmieren kann, wird man das nach einer gewissenhaften Einarbeitung in die Materie auch überall können, sofern man bereit ist, etwas dafür zu tun, denn umsonst gibt es eigentlich nichts bei solchen Dingen, mogeln geht hier leider (oder zum Glück) nicht, man muss was dafür tun, in der Regel viele Jahre Wissen und Erfahrung sammeln.

@Gregor Jasinski
Ich muss gestehen, ich liebe MVVM. Am Anfang war es ungewohnt und ein wenig tricky, da hatte ich ein wenig gelitten. Ich arbeite voll MVVM konform(In Anwendungen, Control-Klassenbibliotheken nicht), also kein CodeBehind in Anwendungen, wäre aber im Zweifel bereit für ein paar Zeilen CodeBehind. Bisher kam ich ohne CodeBehind aus, abgesehen von CustomControls. Da hab ich dann Klasse(n) + ResourceDictionary. Aber ganz ehrlich, bei Custom-Controls habe ich mehr gelitten als beim lernen, verstehen und anwenden des MVVM-Patterns.

Kleine Anmerkung dazu. KalendermonatModel da finde ich den Namen unpassend, weil keine Models sondern ViewModels als DataContext für die Windows festgelegt werden. KalendermonatViewModel würde passen.

Eine Model Klasse hält die Daten, wie z.B. in Forms eine Zeile vom DataTable

Kleines einfaches Beispiel, sollte deutlich machen, wofür Models da sind.