C# / WPF ObservableDictionary

Leider sieht das .NET Framework bisher keine native Implementierung für ein ObservableDictionary vor. Wer trotzdem das Dictionary Pendant zur ObservableCollection haben möchte, muss dieses selbstständig implementieren. Im selben Zug sollte auch ein ObservableKeyValuePair als Pendant zum KeyValuePair implementiert werden. Hierbei sollten die beiden Events CollectionChanged sowie PropertyChanged implementiert werden. Um das Ganze zu realisieren, sollte also zunächst ein ObservableKeyValuePair implementiert werden. Hierbei gibt es verschiedene Möglichkeiten. Ich persönlich bevorzuge hierbei die Verwendung einer sealed class. Natürlich sollte es auch serialisierbar sein und möglichst in jedem Projekt verwendet werden können.  Weiterlesen

Administratorrechte für eine Anwendung erforderlich machen

Es gibt Fälle, in denen man nicht darum herumkommt, für eine Anwendung Administratorrechte erforderlich zu machen. Egal, welche Sprache man wählt, immer kann es nötig sein Aktionen durchzuführen für die mehr Rechte erforderlich sind, als die eines normalen Benutzers. Im Visual Studio kann man hierfür der Anwendung einfach eine Manifest-Datei hinzufügen. Diese Anwendungsmanifest-Datei ist eine simple XML-Struktur. Weiterlesen

Konami Code in einer WPF-Anwendung

Wer kennt ihn nicht, den Konami typischen Cheat-Code für Videospiele. Inzwischen findet der Konami Code in einigen Webseiten, Anwendungen und Spielen seinen Platz. Aber wie wird dieser eigentlich richtig unter WPF implementiert? Nun zunächst einmal sollten wir uns ansehen, wie der Konami Code eigentlich aussieht. Welche Tasten gedrückt werden müssen und in welcher Reihenfolge. Anschließend können wir uns Gedanken über die Implementierung machen und dann muss einem auch noch ein gutes Easter Egg dafür einfallen. Allgemeine Informationen zum Konami Code findet man leicht im Web, z.B. auf Wikipedia. Und hier eine kleine Grafik welche Tasten zum Konami Code gehören:

Up, Up, Down, Down, Left, Right, Left, Right, B, A

Konami Code Tasten

Weiterlesen

Laptop oder Tablet? Erkennen und richtig Handeln!

Durch Windows 8 ist eine ganz neue Form von „mobilen“ Anwendungen auf den Markt gekommen. Die Windows 8 Apps. Ebenso kamen Systeme dazu, die sowohl Tablet als auch Laptop sind und ebenso welche, die beides sein und sich zur Laufzeit ändern können. Passend dazu kamen auch relativ zeitnah die ersten Anwendungen, die auf dieses Verhalten entsprechend reagieren und sich mit jeweils einer anderen angepassten Oberfläche zur Schau stellen.

Die hierfür notwendige API gibt es leider bei Intel nur für C++. Aber mithilfe von P/Invoke kann dies auch ganz einfach mit C# und WPF verwendet werden.

Weiterlesen

Simpler SplashScreen in WPF/C#

Um unter WPF/C# einen simplen SplashScreen anzuzeigen, benötigt es keinerlei Zusätze, außer einer Grafik die angezeigt werden soll. Es ist nicht einmal erforderlich ein eigenes Fenster zu erstellen – insofern keine komplexen Sachen wie Fortschrittsanzeige etc. gewünscht sind (hierfür kann folgendes verwendet werden: http://www.codeproject.com/Articles/38291/Implement-Splash-Screen-with-WPF). Für eine einfache Anzeige hingegen benötigt es nur eine Referenz auf den „System.Windows“ Namespace und schon kann in der „OnStartup“-Methode der App.xaml.cs ein SplashScreen angezeigt werden.

SplashScreen splash = new SplashScreen("SplashScreenImagePath.Type");
splash.Show(true);

Dies genügt bereits, um den SplashScreen anzeigen zu können. Das „true“ in der „Show“-Methode sorgt hierbei für ein Auto-Close, sobald das Hauptfenster angezeigt wird, andernfalls kann mittels „Close“-Methode das schließen ausgelöst werden.

WPF Lokalisierung

Eine häufige Anforderung im Berufsalltag ist es eine Anwendung in mehreren Sprachen anzufertigen. Während C# / VB hierfür sehr simpel auf RESX-Dateien zugreifen kann, ist vielen nicht klar, dass WPF dies ebenfalls beherrscht. Wie das ganze in C# funktioniert, kann älteren Blog-Beiträgen zur SmallMVVM-Reihe entnommen werden, da dies dort bereits Anwendung gefunden hat. Die RESX-Dateien werden hierfür genauso angelegt wie bereits unter C#, d.h. „Resources.de-DE.resx“ für z.B. Deutsch und „Resources.resx“ für die Standardwerte. Sollte der Eintrag in der speziellen Sprache nicht vorhanden sein, wird standardmäßig der aus der normalen Ressource verwendet, also aus der Standard-Datei.

Um das ganze nun in WPF nutzen zu können, muss zunächst ein „xmlns“, ein WPF-Using, angelegt werden. Dieser sieht wie folgt aus:

xmlns:resx="clr-namespace:<DefaultNamespaceOfProject>.Properties"

Anschließend können die Controls ein normales Binding auf Werten aus der genannten Resourcedatei durchführen. Hier sollte beachtet werden, dass dies nur String-Texte sind – Lokalisierungen eben. Das Ganze ist nicht für Einstellungen zu verwenden, dafür gibt es eigene Mechanismen.

<Label Content="{x:Static resx:Resources.<NameOfYourResource>}" />

Interessanter .NET-Blog

Ein neuer, dennoch bereits jetzt hochinteressanter Blog hat vor wenigen Tagen das Licht der Welt erblickt. Der Autor bringt hier bis jetzt zwar ausschließlich Themen aus dem Bereich „WPF“ zum Vorschein, dies jedoch in wirklich kurzen Abständen. So haben sich zwischen dem 16. und 22. Mai bereits 8 Beiträge zu interessanten und vor allem sehr hilfreichen Themen angesammelt. Jeder der an diesen Beiträgen Interesse hat, kann nun folgendem Link folgen: http://xp-development.blogspot.de/

Der Weg zum eigenen MVVM-Framework – Part 4 (Einbindung der Services-Funktionalität)

Weiter geht es mit unserer Reihe zum eigenen Framework. Dieses Mal kümmern wir uns um die Einbindung unserer Service-Funktionen. Also quasi das Registrieren, das rückgängig machen einer Service Registration sowie das holen von Services. Aber zunächst einmal sollten wir klären, was ein Service ist. Ein Service ist ein Dienst, welcher innerhalb einer gewissen Gültigkeits-Reichweite definiert wird. In diesen Fall sind die Services alle für die Applikation und auch nur innerhalb dieser sichtbar. Hierbei sollte man wissen, dass dies bei unserer Umsetzung nicht mehr darstellt als eine Interface gesteuerte Singleton Sammlung unserer Klassen. Auch wird dies nun das Komplexeste, was unser Framework bisher zu bieten hat. Erneut werden wir wieder so vorgehen, das zunächst die Definitionen erfolgen anschließend die Tests und zum Abschluss die Implementierung. Ebenfalls sollte beachtet werden, dass das Wissen aus diesen Part noch relevant sein wird in zukünftige Parts. Aber nun gut lasst und das proggen beginnen!
Weiterlesen

Der Weg zum eigenen MVVM-Framework – Part 3 (Einbindung der Core-Funktionalität)

Dieses Mal wollen wir uns darum kümmern, die noch offene Kern-Funktionalität komplett einzubinden. Dies wäre jedoch für die erste Version dieses Frameworks lediglich eine Klasse welche die Standard.NET-String-Klasse um einige Funktionen erweitert. Aber nichts des so trotz lasst und damit beginnen, den auch diese Klasse will erst mal geschafft sein! Beginnen wir also erneut damit, zunächst die Ordner Struktur festzulegen, in welcher unsere Klasse einmal liegen soll.Anschließend werden wir wieder die leere Klasse definieren. Wenn dies auch geschehen ist, wird es aufgrund des Grey-Box-Testverfahren dazu übergehen, die UnitTests zu implementieren. Und zu guter Letzt wird natürlich wieder die eigentliche Funktionalität implementiert. Nun gut, also lasst uns beginnen!
Weiterlesen

Der Weg zum eigenen MVVM-Framework – Part 2 (Implementierung bestehender Funktionen)

In diesen Part kümmern wir uns um die Einbindung der bereits im Blog entstanden Funktionen (ViewModel, ExtendedPropertyBase sowie PropertyChangedBase). Um hierbei den Grey-Box-Verfahren zu entsprechen, werden zunächst alle Grundgerüste der Reihe nach angelegt, anschließend die UnitTests und erst dann die Implementierung der Funktionalität. Beginnen wir mit der Definition, was sinnvoll zu testen ist. Zunächst ist es natürlich Sinnvoll unsere beiden Property-Klassen “PropertyChangedBase” sowie “ExtendedPropertyBase” nahezu vollständig zu testen (AusnahmeDispose). Aber was ist mit unserer ViewModel-Klasse? Hier finde ich, sind Tests un-sinnvoll Die nötigen Tests wären aufgrund der Asynchronität komplex und da wir nur fertige .NET-Funktionen direkt aufrufen, ist das testen auch nahe zu unsinnvoll.  Weiterlesen