How-To: Regionen und mehrere Dialoge in WPF darstellen

Eine Sache die bis heute in WPF fehlt, ist eine anständige MessageBox, weswegen man sich diese in aller Regel selbst programmieren muss oder auf die Implementierung der Windows Forms zurückgreift. Aber auch außerhalb der typischen Szenarien die mit den bekannten MessageBoxen abgedeckt werden, ist es immer wieder hilfreich mehrere UserControls innerhalb eines Windows oder in Form von sich überlagernden Dialogen darzustellen. Mir wurde die Frage gestellt wie man dies realisieren könnte und da ein entsprechendes Blockpost wieder sehr lang geworden wäre, habe ich mich dazu entschieden ein Video zu machen. Interessant dabei dürfte sein, dass man das darin erklärte Vorgehen zum Anzeigen eines Popups (damit sind nicht WPF Popups gemeint) auch und gerade mit Microsofts Prism sehr gut nutzen kann.

Weiterlesen »

Prism: Target einer Navigation finden

Eine Sache die ich immer mal wieder bei Kisoksystemen brauche, ist die Ermittlung eines Navigationsziels mit Prism. Das heißt, ich habe einen bestimmten Workflow und sobald von einer View in eine andere navigiert werden soll, muss ich noch ein paar Aktionen ausführen, falls die Zielansicht bestimmte Eigenschaften aufweist.

Weiterlesen »

How-To: UserControls in ItemsControl mit Überschriften trennen

Eine der wichtigsten Gründe Prism einzusetzen ist die Möglichkeit die GUI in Regionen aufzuteilen. Jede dieser Regionen wird als Content-, Items- o.ä. Control repräsentiert und kann dann zur Laufzeit mit 1 (ContentControl) bis n (Items– oder TabControl) UserControls bestückt werden. Auf diese Weise wird die eigentliche Benutzeroberfläche lose gekoppelt und kann ohne größeren Aufwand an neue Anforderungen angepasst werden. Ein immer wiederkehrendes Problem stellt für mich dabei die Nutzung des ItemsControl dar. Jenes zeigt die einzelnen Views in Form einer Liste an, was unter Umständen etwas langweilig und verwirrend wirken kann. Aus diesem Grund bietet es sich an, jene Views durch Überschriften oder Abgrenzungen voneinander zu trennen, aber wie kriegt man das hin? Kann man es evtl. auch ohne Prism verwenden? Und vor allem wie schafft man es mit möglichst wenig Aufwand?

Weiterlesen »

Pattern, Clean Code & Prism – Vortrag an der HTW-Dresden vom 16.01.2012

Das Semester neigt sich dem Ende, die Vorlesungen sind fast alle gehalten und so ist jetzt eine gute Möglichkeit den Studenten ein wenig Wissen abseits des eigentlichen Lehrplans zu vermitteln. Dank Professor Nestler hatte ich auf diese Weise wieder die Möglichkeit einen Spezialvorlesung an der HTW-Dresden zu halten. Nach dem ich mich beim letzten Mal im Juni vor allem der agilen Entwicklung und dem automatisierten Test gewidmet hatte, ging es dieses Mal um Pattern, Clean Code und Prism.

Weiterlesen »

Artikel zum Lazy-Pattern in der Dotnetpro 09 / 2011

In der aktuellen Dotnetpro 09/2011 findet sich ein Artikel von mir mit der Überschrift „Faul sein lohnt sich: das Lazy-Pattern richtig einsetzen.“ Darin widmet ich mich weitestgehend dem Einsatz des Lazy Patterns abseits vom bisher für die meisten Leute bekannten Vorgehen des Lazy Loadings bei Datenbankzugriffen. Im Grunde ist der Artikel eine erweiterte Betrachtung dessen was ich bereits über Lazy<T> und die damit verbundenen Probleme hier im Blog geschrieben habe. Dabei erläutere ich natürlich zunächst die Grundlagen des Lazy Pattern, sowie der Lazy<T>-Klasse. Danach widme ich mich der Verwendung des LazyInitializiers, der Klasse ThreadLocal<T> und den möglichen Probleme mit dem Large Object Heap bei Lazy Initialization bzw. Evaluation von sehr großen Datenmengen. Als Beispiel für die praktische Verwendung von Lazy<T>, wird zuletzt noch auf IoC-Frameworks allgemein und das Managed Extensibility Framework im Speziellen eingegangen bevor ich mit einer kurzen Zusammenfassung

Weiterlesen »

Fundstück: MVVM in the Box

MVVM ist wohl eines der meist diskutierten Themen wenn es um WPF geht. „Warum brauche ich das?“ „Wie setze ich X denn dann um?“ „Warum ist Code-Behind so schlimm?“ Alles Fragen die einem immer wieder begegnen und immer wieder aufs neue beantwortet werden wollen. Einige Gründe die zu all dem führen sind der mit MVVM verbundene Aufwand, die fragmentierten Erklärungen die über das ganze Netz verstreut sind und das solide WPF-Wissen das man benötigt um die Gänze des „Problems“ überhaupt erst erfassen zu können. Vorallem die Frage nach dem „Wie“, kann schnell ausarten wenn es darum geht wie bspw. Dialoge gesteuert werden, wie das ViewModel richtig erzeugt wird und wie es der View übergeben werden sollte.

Weiterlesen »