C and it's sharp http://berndhengelein.de berndhengelein.de Sat, 30 Oct 2010 20:08:41 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 Compiler warning CS0067 – es muss nicht immer #pragma sein http://berndhengelein.de/2010/07/compiler-warning-cs0067-es-muss-nicht-immer-pragma-sein/ http://berndhengelein.de/2010/07/compiler-warning-cs0067-es-muss-nicht-immer-pragma-sein/#comments Wed, 28 Jul 2010 23:15:10 +0000 Bernd http://berndhengelein.de/?p=331 warningSignDa ist es wieder. Der Compiler spuckt die Warnung CS0067 “The event ‘XXX’ is never used” aus. Das kann z.B. passieren, wenn das Interface ICommand implementiert wird, das Command aber immer ausführbar sein soll. Das Event CanExecuteChanged muss also nie gefeuert werden:

 

 

public class SomeCommand : ICommand
{
	public void Execute(object parameter)
    {
		// do sth.
	}

	public bool CanExecute(object parameter)
    {
		return true;
	}

	public event EventHandler CanExecuteChanged;
}

Bei obiger Imlementierung bekommt man beim Übersetzten die Compiler Warnung CS0067:

warning CS0067: The event ‘CommandDemo.SomeCommand.CanExecuteChanged’ is never used

Was einem als erstes (zumindest mir) einfällt die Warning zu “beheben”, ist sie mit einem #pragma Statement kurzzeitig aus- und wieder einzuschalten:

#pragma warning disable 0067
	public event EventHandler CanExecuteChanged;
#pragma warning restore 0067

So richtig gut gefällt diese Lösung aber nicht. Bei Implementierungen, wo das Event später vielleicht doch einmal gefeuert wird, ist die Wahrscheinlichkeit ziemlich hoch, dass diese #pragma Statements vergessen werden und im Code verbleiben. Das ist nicht schön. Aber es gibt eine andere, (mittlerweile meiner Ansicht nach bessere) Lösung:

public event EventHandler CanExecuteChanged { add{} remove{} }

Durch das Hinzufügen der leeren Eventaccessors “add” und “remove” mache ich klar, dass dieser Event nicht verwendet wird. Da das Event sowieso nie gefeuert wird, ändert sich auch für den potentiellen Konsumenten des Events nichts. Wenn in einer späteren Phase dieser Event doch einmal ausgelöst werden soll, wird der Entwickler sofort mit einem Kompilerfehler darauf hingewiesen, das dies nicht möglich ist. Die leeren “add” und “remove” Accessoren müssen also entweder wieder entfernt oder entsprechend vollständig implementiert werden ==> der Code bleibt sauber.

Wie man sieht, muss man also nicht sofort zum #pragma greifen, wenn man mit der Warnung CS0067 konfrontiert wird. Das Hinzufügen der leeren Eventaccessoren bietet eine elegante und saubere Lösung mit dem Fall umzugehen.

]]>
http://berndhengelein.de/2010/07/compiler-warning-cs0067-es-muss-nicht-immer-pragma-sein/feed/ 2
NUnit mit .NET 4.0 Assemblies verwenden http://berndhengelein.de/2010/07/nunit-mit-net-4-0-assemblies-verwenden/ http://berndhengelein.de/2010/07/nunit-mit-net-4-0-assemblies-verwenden/#comments Mon, 19 Jul 2010 18:41:33 +0000 Bernd http://berndhengelein.de/?p=321 lightbulb Bei unseren Projekten stellen wir gerade von Visual Studio 2008 auf Visual Studio 2010 mit .NET 4.0 um. Der Umstieg läuft recht problemlos. Die Unittests sind alle mit dem NUnit Unittest Framework entwickelt. Ein kurzer Blick auf die NUnit Homepage zeigt, dass die aktuelle Version 2.5.5 mit .NET 4.0 funktioniert. Also, Version runtergeladen, entpackt und alles kompiliert noch. Als Entwickler verwende ich den Unittestrunner von Resharper. Und siehe da, alle Tests laufen noch und sind grün. Perfekt!

Auf dem Buildrechner sieht es leider nicht so gut aus. Die Unittests laufen überhaupt nicht mehr. Dort werden die Tests mit dem Consolerunner von NUnit ausgeführt. Ein Aufruf desselben auf meinem Rechner bringt folgende (bzw. eine ähnliche) Ausgabe:

Execution Runtime: net-2.0
Unhandled Exception:
System.BadImageFormatException: Could not load file or assembly ‘C:\Users\Bernd\documents\visual studio 2010\Projects\SomeProjects\SomeProject.Unittests\bin\Debug\SomeProject.Unittests.dll’ or one of
its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
File name: ‘C:\Users\Bernd\documents\visual studio 2010\Projects\SomeProjects\SomeProject.Unittests\bin\Debug\SomeProject.Unittests.dll’

Was ist da los?

Die NUnit Assemblies selbst sind mit .NET 2.0 kompiliert. Der Consolerunner von NUnit läuft also auch mit der CLR 2.0 und kann somit keine Assemblies laden, die mit .NET 4.0 erstellt wurden. Glücklicherweise haben die Entwickler von NUnit genau für diese Fälle einen Kommandozeilenparameter für nunit-console.exe eingebaut. Mit dem Schalter “/framework” kann man angeben mit welcher .NET Runtime die Test ausgeführt werden sollen. Der korrekte Aufruf lautet also:

nunit-console.exe /framework:v4.0.30319 bin\Debug\SomeProject.Unittests.dll

Jetzt tritt keine Exception mehr auf und die Tests laufen auch auf der Console sauber durch.

Der Schalter war übrigens vor dem Umstieg (es wurde .NET 3.5 SP1 verwendet) nicht notwendig, da .NET 3.5 dieselbe CLR wie .NET 2.0 verwendet.

]]>
http://berndhengelein.de/2010/07/nunit-mit-net-4-0-assemblies-verwenden/feed/ 2
TDD – ein Garant für heiße Diskussionen http://berndhengelein.de/2010/03/tdd-ein-garant-fr-heie-diskussionen/ http://berndhengelein.de/2010/03/tdd-ein-garant-fr-heie-diskussionen/#comments Sun, 28 Mar 2010 19:12:26 +0000 Bernd http://berndhengelein.de/?p=317 tdd

Beim allmonatlichen Treffen der .NET User Group Franken hatten wir am 25.03.2010 einen interaktiven Vortrag zum Thema Test Driven Development (TDD). Interaktiv deshalb, weil die Vortragenden Jürgen Laude und Jan Welker an einem praktischen Beispiel mit Live Coding gezeigt haben, wie TDD funktioniert. Dabei handelte es sich nicht um ein konstruiertes Beispiel, sondern um ein Problem, welches Jan vor ein paar Jahren schon einmal in einem Projekt gelöst hatte. Es wurde ein spezieller Parser für RSS Feeds entwickelt, die nicht standardkonform aufgebaut sind.

Schon die Anzahl der Gäste an diesem Abend (mit knapp 40 Teilnehmern war der Raum prall gefüllt) hat gezeigt, dass das Thema Testen und testgetriebene Entwicklung viele Softwareentwickler umtreibt. Dementsprechend zahlreich und kontrovers waren auch die Fragen und Diskussionen an dem Abend. Ich möchte hier zu ein paar der diskutierten Punkten meinen Kommentar abgeben.

TDD dient nicht dazu Fehler zu finden

Ein Punkt, der auch von den Referenten angesprochen wurde ist, dass mit TDD nicht in erster Linie Fehler gefunden, sondern verhindert werden sollen. Dadurch, dass die Tests vor dem zu testenden Produktionscode geschrieben werden, ist man gezwungen, testbaren, modularen und lose gekoppelten Code zu schreiben. TDD ist also das Werkzeug des Entwicklers für gutes Design. Hat man sich dieses Sicherheitsnetz aus Unit Tests geschaffen, kann man viel furchtloser mit dem Code arbeiten. Während der ständigen Refaktorierungen, die bei TDD üblich sind, wird man sofort auf Fehler hingewiesen, die man eventuell eingebaut hat. Auch wird sichergestellt, dass sich beim Implementieren neuer Features keine Fehler in die bereits bestehende Funktionalität eingeschlichen haben.

Sollten Internas einer Klasse getestet werden?

Meine Vermutung ist, dass diese Frage hauptsächlich von Leuten aufgeworfen wird, die den Code nicht testgetrieben entwickelt haben. Wenn Unittests im Nachhinein geschrieben werden, schleichen sich Zweifel ein, ob auch wirklich alles getestet ist und ob nicht doch was vergessen wurde. Lieber eine Methode zuviel als zuwenig getestet. Bei testgetriebener Entwicklung wird gegen das öffentliche Interface getestet. Die privaten Methoden entwickeln sich während der Refaktorierungschritte. Es wird damit zu jedem Zeitpunkt sichergestellt, dass die privaten Methoden implizit über das öffentliche Interface mitgetestet werden. Wenn man den Drang verspürt eine private Methode testen zu wollen, ist das ein Code Smell der auf eine Umstrukturierung der Klasse hindeutet.

Unittests können Integrations-, Akzeptanz- oder Systemtests nicht ersetzen

Wenn im Zuge von TDD erstellte Unittests keine Fehler finden, müssen diese Fehler natürlich durch andere Tests gefunden werden. Hier können Integrationstests (die durchaus auch mit einem Unittest Framework geschrieben werden können) und natürlich auch Systemtests helfen. Wenn die Projektstruktur es zulässt, können auch Akzeptanztests (z.B. mit FitNesse) erstellt werden, die es leichter machen direkt mit dem Kunden zu kommunizieren. Bei Akzeptanztests werden die Tests in einer Sprache beschrieben, die sowohl der Entwickler als auch der Kunde versteht.

Natürlich gibt es auch andere Meinungen zu dem Thema. René Drescher-Hackel hat z.B. auf seinem Blog den Post Gedanken zum Test Driven Development (TDD) veröffentlicht.

Es leuchtet ein, dass ein zweistündiges Event zum Thema TDD nicht alle Fragen beantworten und alle Zweifel ausräumen kann. Vielmehr ist es ein Denkanstoß und vielleicht ein Motivationsschub um die Ärmel hochzukrämpeln und TDD in eigenen Projekten anzuwenden und auszuprobieren.

]]>
http://berndhengelein.de/2010/03/tdd-ein-garant-fr-heie-diskussionen/feed/ 0
Fehler bei der Installation des Visual Studio 2010 RC http://berndhengelein.de/2010/02/fehler-bei-der-installation-des-visual-studio-2010-rc/ http://berndhengelein.de/2010/02/fehler-bei-der-installation-des-visual-studio-2010-rc/#comments Mon, 15 Feb 2010 12:22:44 +0000 Bernd http://berndhengelein.de/?p=312 Ich hatte das Problem, dass sich der Release Candidate von Visual Studio 2010 auf dem Windows XP Firmenrechner nicht installieren ließ. Das Setup brach mit der Fehlermeldung

“A problem has been encountered while loading the setup components. Canceling setup”

ab.

Eine Suche nach obigem Fehlertext hat keine Antwort zu Tage gefördert. Da ist es gut zu wissen, dass im %TEMP% Verzeichnis während des Setups diverse Log Dateien angelegt werden.

In dem File “dd_error_vs_vstscore_100.txt” fand sich folgender Eintrag:

[02/15/10,10:17:33] vs70uimgr: [2] UI Thread exiting with error code: -2147172341.
[02/15/10,10:17:33] setup.exe: [0] StartUIManager(), RunScenario failure
[02/15/10,10:17:33] setup.exe: [2] CSetupManager::RunIntro() – Failed to Start the UI Manager
[02/15/10,10:17:36] setup.exe: [2] CSetupManager::RunLoadSetup() – Failed to Run the Intro

Mit dieser Zusatzinformation hat mich die Suchmaschine meiner Wahl dann auch zu einem MSDN Forum Artikel geführt, welcher die Lösung parat hat: http://social.msdn.microsoft.com/Forums/en-US/setupprerelease/thread/dbcdcd52-d162-4460-9920-33c9ab54b36f

Der Lösung bestand darin, über den “Settings” Dialog in der Language Bar die Unterstützung für Schrifterkennung zu entfernen. Dannach lief das Setup ohne Probleme durch.

]]>
http://berndhengelein.de/2010/02/fehler-bei-der-installation-des-visual-studio-2010-rc/feed/ 4
WPF 4.0 – Verbesserungen beim Textrendering http://berndhengelein.de/2009/11/wpf-4-0-verbesserungen-beim-textrendering/ http://berndhengelein.de/2009/11/wpf-4-0-verbesserungen-beim-textrendering/#comments Fri, 13 Nov 2009 22:15:58 +0000 Bernd http://berndhengelein.de/?p=302 Am 22. März 2010 wird Visual Studio 2010 als finales Produkt verfügbar sein. Damit ist auch eine neue Version des .NET Frameworks verbunden, .NET 4.0. Auch für WPF Entwickler wird so einiges Neues in .NET 4.0 enthalten sein. Lester Lobo stellt auf seinem Blog in der Reihe “New WPF 4 Features” die wichtigsten Neuerungen vor.

Natürlich will ich nicht alles von Lester wiederkauen, aber eine Neuerung möchte ich doch herausstellen. Bei bisherigen WPF Anwendungen ist die Darstellung von Text mit kleiner Schrift teilweise etwas (manche sagen sogar sehr) unscharf. Der Artikel Textclarity in WPF auf windowsclient.net geht ziemlich gut auf diese Problematik und mögliche Workarounds ein. In .NET 4.0 ist es nun möglich das Textrendering mit zwei attached properties zu beeinflussen.

TextOptions.TextFormattingMode kann mit zwei unterschiedlichen Werten belegt werden. Einmal mit Ideal, was dem bisherigen WPF Textrendering entspricht oder mit Display, was die Darstellung bei kleinen Schriftarten schärfer aussehen lässt.

TextOptions.TextRenderingMode legt den Algorithmus für das Antialiasing fest und kann die Werte Auto, Aliased, Greyscale oder ClearType haben.

Der folgende Screenshot zeigt einige der Einstellungen für kleine und große Schrift:

WPF4TextImprovements

Bei der kleinen Schrift sieht man eine deutliche Verbesserung der Lesbarkeit des angezeigten Textes. Das unscharfe, verwaschene Schriftbild ist einer klaren Darstellung gewichen, was vorallem bei Businessanwendungen mit WPF sehr wichtig ist. Wer jetzt schon die neuen Features von .NET 4.0 ausprobieren möchte, kann sich weiterhin die Beta 2 von Visual Studio 2010 hier herunterladen.

]]>
http://berndhengelein.de/2009/11/wpf-4-0-verbesserungen-beim-textrendering/feed/ 0
INotifyPropertyChanged – Varianten für die Implementierung http://berndhengelein.de/2009/09/inotifypropertychanged-varianten-fr-die-implementierung/ http://berndhengelein.de/2009/09/inotifypropertychanged-varianten-fr-die-implementierung/#comments Wed, 02 Sep 2009 19:27:56 +0000 Bernd http://berndhengelein.de/?p=284 Wer mit WPF programmiert, kennt INotifyPropertyChanged. Das allgegenwärtige Interface, mit dem Änderungen z.B. von einem ViewModel zu einem daran gebunden UI Element propagiert werden. Eine typische Implementierung von INotifyPropertyChanged sieht etwa so aus:

INotifyPropertyChanged Horror

Drei Sachen fallen ins Auge

  1. jedes ViewModel muss INotifyPropertyChanged implementieren, d.h. den PropertyChanged Event anbieten und eine Methode zum Feuern des Events haben.
  2. die EventArgs für den PropertyChanged Event bekommen als Parameter einen String, der dem Namen der Property entspricht.
  3. der Code ist “zugemüllt” mit Infrastrukturcode, der eigentlich nichts zur Logik des Objekts beiträgt
    Der erste Punkt lässt sich relativ einfach lösen, indem man eine ViewModel Basisklasse macht, die diese Aufgaben übernimmt.
    Basisklasse für ViewModels
    public abstract class ViewModelBase : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;
    
        protected void OnPropertyChanged(string propertyName)
        {
            PropertyChangedEventHandler handler = PropertyChanged;
            if (handler != null)
            {
                handler(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }

Beim zweiten Punkt wird es dann schon schwieriger. Hier gibt es mehrere Ansätze, die Strings loszuwerden.

Am häufigsten trifft man wohl eine Variante mit Lambda Expressions an. Die Implementierungen reichen von einer Extensionmethod für den PropertyChangedEventHandler bis zu einer generischen ViewModel Basisklasse, welche das abgeleitete ViewModel als Type Parameter bekommt. Hier ein paar Links zum Nachlesen:

J.P. Hamilton – Generische ViewModel Basisklasse

Stefan Lieser – Implementierung direkt im ViewModel

Eric De Carufel – Extensionmethod für PropertyChangedEventHandler

 

Andere Lösungen, die ich gefunden habe:

Alkampfer – INotifyPropertyChanged mit CodeDom implementieren

Ayende – INotifyPropertyChanged mit Castle Dynamic Proxy

Mike Saunders – INotifyPropertyChanged mit PostSharp Aspekt

Richard Banks – INotifyPropertyChanged mit PostSharp Aspekt

 

Dann gibt es noch die den Verfechter von UpdateControls, Michael L. Perry. UpdateControls ist eine Open Source Bibliothek auf CodePlex, die es erlaubt, Änderungen von Eigenschaften auch ohne INotifyProperyChanged zu propagieren und z.B. an WPF Controls zu binden. Eine gute Einführung in UpdateControls kann man beim CODE Magazin lesen.

 

Mir gefallen bisher die Lösungen mit PostSharp am Besten. Damit lassen sich alle drei Punkte auf einmal erschlagen.

  1. Mit einem PostSharp Attribut, das auf die ViewModel Klasse geklebt wird, lässt man die INotifyPropertyChanged Implementierung automatisch einweben.
  2. Es gibt keine Magic Strings mehr, da auch das Feuern des ProperyChanged Events automatisch eingewoben wird. Verschreiber sind dadurch ausgeschlossen, Refactoring ist kein Problem.
  3. Der Code bleibt sauber und lesbar, da der ganze Notifikationscode erst nachträglich hinzugefügt wird.
    Der nächste Schritt

Ein Kollege von mir hatte die Idee, die Verwendung von PostSharp in Verbindung mit dem MVVM Pattern noch einen Schritt weiter zu treiben. Wir verwenden jetzt ein [ViewModelAspekt] PostSharp Attribut, mit dem die ViewModels versehen werden.

[ViewModelAspect]
public class MyViewModel
{
    private string _name;

    public string Name
    {
        get{ return _name;}
        set{ _name = value;}
    }

    public void Save()
    {
        // do sth.
    }
}

Dieser Aspekt macht folgendes:

  • Implementierung von INotifyPropertyChanged
  • Für alle public Properties wird im Setter der PropertyChanged Event gefeuert
  • Für alle public void Methoden wird eine Command Property erzeugt, welche mit Hilfe des Delegate/Relay Commands wiederum diese Methode aufruft.
    Dadurch haben wir es geschafft, den Overhead für die Verwendung des MVVM Patterns sehr gering zu halten. Die nächsten Wochen werden zeigen, ob sich diese Variante bewährt und alle Use Cases damit abgedeckt werden können.
]]>
http://berndhengelein.de/2009/09/inotifypropertychanged-varianten-fr-die-implementierung/feed/ 6
WPF Grundlagen – Wie finden Applikation und Fenster zusammen? http://berndhengelein.de/2009/07/wpf-grundlagen-wie-finden-applikation-und-fenster-zusammen/ http://berndhengelein.de/2009/07/wpf-grundlagen-wie-finden-applikation-und-fenster-zusammen/#comments Wed, 29 Jul 2009 21:40:43 +0000 Bernd http://berndhengelein.de/?p=273 Die Projektvorlagen dieser Welt machen es dem Entwickler heutzutage sehr einfach, zu einer lauffähigen Anwendung zu kommen. Ein paar Klicks und schon ist das Gerüst z.B. für eine WPF Applikation fertig. Dabei passiert aber auch so manches hinter den Kulissen, was auf den ersten Blick nicht so leicht ersichtlich ist. Deswegen stellen wir uns heute die Frage, wie bei einer vom Visual Studio generierten WPF Anwendung, das Applikationsobjekt und das Hauptfenster zusammenfinden.

Wie sieht die Struktur einer WPF Anwendung aus, die mit dem Projekttemplate von Visual Studio 2008 erstellt wurde?

 Struktur einer WPF Anwendung in VS 2008

Der Screenshot zeigt den Aufbau einer solchen WPF Applikation. Es fallen auf Anhieb zwei Teile auf, die jeweils aus einem XAML File und einem C# File bestehen:

  • App.* – beschreiben das Applikationsobjekt
  • Window1.* – beschreiben das Hauptfenster der Applikation
    Und, wie nicht anders zu erwarten, läuft das Programm wenn F5 im Studio gedrückt wird. Aber was passiert hier? Dazu werfen wir einen Blick auf den Sourcecode.

XAML File für das Haupfenster

<Window x:Class="WpfApplication.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Grid>
    </Grid>
</Window>

Hier gibt es nichts spektakuläres zu sehen. Es wird ein Objekt vom Typ Window definiert, ein paar Eigenschaften wie Titel, Höhe und Breite angegeben und zwei XML Namespaces eingebunden. Interessant ist der Teil “x:Class=”WpfApplication.Window1”. Mit dem Attribut x:Class wird angegeben, dass zu diesem XAML Code noch ein weiterer Teil, nämlich der C# Teil gehört. “WpfApplication” gibt hierbei den Namespace und “Window1” den Klassennamen an. Ein Blick in das zugehörige C# File zeigt dann auch eine partielle Klasse Window1.

C# File für das Hauptfenster

using System.Windows;

namespace WpfApplication
{
    /// <summary>
    /// Interaction logic for Window1.xaml
    /// </summary>
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();
        }
    }
}

Bei einem frisch erstellten Projekt ist diese Code-Behind Datei bis auf den Aufruf von “InitializeComponent()” ziemlich leer (die überflüssigen “using” Anweisungen habe ich gleich vom Resharper entfernen lassen).

 

XAML File für die Applikation

<Application x:Class="WpfApplication.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    StartupUri="Window1.xaml">
    <Application.Resources>
    </Application.Resources>
</Application>

Der Aufbau ist ähnlich wie bei dem Window. Hier taucht erstmals eine Verbindung zwischen der Applikation und dem Fenster auf, indem das StartupUri Attribut auf den Dateinamen des XAML Files des Fensters gesetzt wird.

C# File für die Applikation

using System.Windows;

namespace WpfApplication
{
    /// <summary>
    /// Interaction logic for App.xaml
    /// </summary>
    public partial class App : Application
    {
    }
}

Hier herrscht gähnende Leere. Die partielle Klasse des Applikationsobjektes ist komplett leer. Jetzt stellt sich die Frage, wo denn die “Main” Methode unserer Applikation ist. Irgendwie muss die Anwendung ja gestartet werden. Hier hilft uns der “Show All Files” Button im Solution Explorer weiter:

/feed/Show_all_files_in_Solution_Explorer/index.html

Jetzt werden auch alle temporären Dateien angezeigt, die während des Kompiliervorgangs entstanden sind. Aus dieser Vielzahl sehen wir uns ein File ein bisschen genauer an:

App.g.cs

Das ‘g’ im Dateinamen steht für “generated”. Es handelt sich hier also um einen generierten Teil der Applikationsklasse. Ich picke mal den interessanten Teil heraus:

...
public void InitializeComponent() {

    #line 4 "..\..\App.xaml"
    this.StartupUri = new System.Uri("Window1.xaml", System.UriKind.Relative);

    #line default
    #line hidden
}

/// <summary>
/// Application Entry Point.
/// </summary>
[System.STAThreadAttribute()]
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
public static void Main() {
    WpfApplication.App app = new WpfApplication.App();
    app.InitializeComponent();
    app.Run();
}
...

Et voilà, hier findet sich auch eine Main() Methode welche den Einstiegspunkt für das Programm darstellt. In InitializeComponent() findet sich auch wieder die StartupUri Eigenschaft, die in App.xaml gesetzt wurde. Durch das setzen dieser Eigenschaft wird das von der URI referenzierte Fenster beim Start der Applikation angezeigt und als dessen Hauptfenster gesetzt (ist also über Application.Current.MainWindow erreichbar).

Auch wenn es den erfahrenen WPF Entwickler vielleicht gelangweilt haben mag – ich finde solche Grundlagen wichtig. Eventuell war ja für den einen oder anderen WPF Einsteiger etwas Neues/Interessantes dabei.

]]>
http://berndhengelein.de/2009/07/wpf-grundlagen-wie-finden-applikation-und-fenster-zusammen/feed/ 3
.NET Open Space Süd 2009 http://berndhengelein.de/2009/07/net-open-space-sd-2009/ http://berndhengelein.de/2009/07/net-open-space-sd-2009/#comments Mon, 13 Jul 2009 18:56:28 +0000 Bernd http://berndhengelein.de/?p=263
.NET Open Space vom 11.07. bis 12.07.2009 in Ulm

Wow! Das war wirklich ein gelungenes Wochenende. Die Rede ist vom ersten .NET Open Space Süd, welcher vom 11.09. – 12.09. in Blaustein bei Ulm stattfand. Nach dem Vorbild der ALT.NET Konferenz in London und dem .NET Open Space in Leipzig haben Thomas Schissler und Alexander Zeitler auch für den Süden der Republik eine Communityveranstaltung der besonderen Art organisiert.

Eine Konferenz ohne Agenda, ohne geplante Vorträge? Kann das funktionieren? Ja, und zwar sehr gut! Die Teilnehmer organisieren sich selbst, machen Themenvorschläge und finden sich dann in Gruppen zusammen um die Themen zu diskutieren. Eine wunderbare Abwechslung zur Berieselung bei den herkömmlichen Veranstaltungen. In Ulm haben auf diese Weise ca. 60 Teilnehmer ihr Wissen und ihre Erfahrung ausgetauscht.

Dabei wurden sowohl technische Themen wie ASP.Net MVC, WPF, ORM, AOP,… unter die Lupe genommen als auch Bereiche wie SCRUM oder Getting Things Done ausführlich diskutiert. Danke an alle Teilnehmer, durch die solch ein Event erst möglich wird.

Um den Kopf wieder frei zu bekommen, darf natürlich auch ein entsprechendes Rahmenprogramm nicht fehlen. Auch hier haben sich Thomas und Alex nicht lumpen lassen und haben uns den Abend mit Bauchtanz und Feuershow verschönt. Wenn dann auch noch das Catering vom lokalen Sportverein so perfekt vonstatten geht, gibt’s wirklich nichts zu meckern.

Wer sich ein Bild machen möchte, findet Bilderserien dazu von Peter, Jan und Albert hier, hier und hier. Weiteres Feedback und zusätzliche Informationen gibt es auf dem Schwarzen Brett.

Bis zum nächsten .NET Open Space – vielleicht schon in Leipzig.

]]>
http://berndhengelein.de/2009/07/net-open-space-sd-2009/feed/ 0
Wie kriege ich mit, ob der Rechner gelockt wird? http://berndhengelein.de/2009/06/wie-kriege-ich-mit-ob-der-rechner-gelockt-wird/ http://berndhengelein.de/2009/06/wie-kriege-ich-mit-ob-der-rechner-gelockt-wird/#comments Wed, 24 Jun 2009 20:31:33 +0000 Bernd http://berndhengelein.de/?p=257 Ja, ja, wenn man es mal weiß, dann ist alles einfach und sonnenklar.  Ich wollte vor kurzem wissen, wie ich in einem Programm darauf reagieren kann, wenn der Computer gesperrt/gelockt wird. Das rauszufinden, hat überraschenderweise recht lange gedauert. Dabei hätte ich nur nach “SystemEvents” googeln müssen. Aber das wusste ich zu dem Zeitpunkt natürlich nicht.

Die SystemEvents Klasse aus dem Microsoft.Win32 Namespace bietet einen Sack voll Events an, um auf Systemereignisse reagieren zu können. Unter anderem gibt es ein SessionSwitch Event:

image

Mit einem kleinen Testprogramm sieht man auch sofort, dass dieses Event gefeuert wird, wenn der Computer gesperrt wird:

static void Main(string[] args)
{
    SystemEvents.SessionSwitch +=
    	(s, e) => Console.WriteLine("Event {0} received...",
                                	e.Reason);
    Console.ReadLine();
}

Ein Sperren und Entsperren ergibt folgende Ausgabe:

Event SessionLock received…

Event SessionUnlock received…

War doch gar nicht so schwer. Im realen Leben solltet ihr aber auf keinen Fall vergessen euch wieder von dem Event abzumelden. Ansonsten kann das Objekt, welches sich an dem Event angemeldet hat, nicht vom Garbage Collector abgeräumt werden.

]]>
http://berndhengelein.de/2009/06/wie-kriege-ich-mit-ob-der-rechner-gelockt-wird/feed/ 0
Fünf Freunde: Action, Predicate, Comparison, Converter und Lambda Ausdrücke http://berndhengelein.de/2009/05/funf-freunde-action-predicate-comparison-converter-und-lambda-ausdrucke/ http://berndhengelein.de/2009/05/funf-freunde-action-predicate-comparison-converter-und-lambda-ausdrucke/#comments Thu, 21 May 2009 21:53:09 +0000 Bernd http://berndhengelein.de/?p=249 Ich habe den Eindruck, dass die generischen Delegates aus dem .Net Framework vielerorts immer noch ein Schattendasein fristen. Mit ein paar einfachen Beispielen die zeigen, wofür man Action, Predicate und Co. verwenden kann, möchte ich Lust auf mehr machen.

Generische Delegates ersparen dem Entwickler die Arbeit eigene Delegates zu deklarieren und kommen häufig in Verbindung mit Containerklassen zur Anwendung.

Als Spielzeugklasse habe ich mir diesmal etwas ganz aussergewöhnliches einfallen lassen. Und zwar eine Klasse Person:

public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
    public bool IsCool { get; set; }

    public override string ToString()
    {
        return String.Format( "{0} is {1}.", Name, IsCool ? "cool" : "not cool" );
    }
}

Dazu erzeugen wir uns noch ein paar "Versuchspersonen":

List<Person> persons = new List<Person>();

persons.Add( new Person {Name = "Karin", Age = 39} );
persons.Add( new Person {Name = "Simon", Age = 23} );
persons.Add( new Person {Name = "Fritz", Age = 34} );
persons.Add( new Person {Name = "Georg", Age = 56} );
persons.Add( new Person {Name = "Susi", Age = 67} );
persons.Add( new Person {Name = "Toni", Age = 45} );

Action<T> Delegate

Der Action<T> Delegate kapselt eine Methode die einen Parameter übergeben bekommt und keinen Wert zurückgibt. Mit .Net 3.5 wurden noch zusätzliche Action Delegates eingeführt, die bis zu vier Parameter bekommen (Action<T1, T2>, Action<T1, T2, T3> und Action<T1, T2, T3, T4>).

Ein Action Delegate wird z.B. als Parameter für die ForEach Methode der Klasse List<T> benötigt. ForEach iteriert über die gesamte Liste und führt für jedes Element die übergebene Methode aus.

Action<T> delegate

Hier ein paar Beispiele:

Informationen über alle unsere Personen auf der Console ausgeben:

persons.ForEach(Console.WriteLine);

In Verbindung mit einem Lambdaausdruck werden alle Personen ganz schnell cool:

persons.ForEach(p => p.IsCool = true);

Predicate<T> Delegate

Der Predicate<T> Delegate kapselt eine Methode die einen Parameter (vom Typ T) übergeben bekommt und true oder false zurückgibt. Es steckt aber auch Semantik in dem Predicate Delegate: er definiert einen Satz von Kriterien und überprüft ob das übergebene Objekt diese Kriterien erfüllt. Das klingt erstmal ziemlich geschwollen, aber ein Beispiel macht das schnell klar.

Predicate<T> delegate

Um z.B. alle Personen die älter als 50 sind zu entfernen, schreiben wir:

persons.RemoveAll( p => p.Age > 50 );

Mit der Methode Exists kann überprüft werden, ob in der Liste Element enhalten sind, die eine bestimmte Bedingung erfüllen:

if (persons.Exists(p => p.Name == "Toni"))
{
    Console.WriteLine("A person with name Toni exists");
}

Comparison<T> Delegate

Der Comparison<T> Delegate kapselt eine Methode die zwei Objekte gleichen Typs vergleicht.

public delegate int Comparison<T>
(
	T x,
	T y
)

Als Rückgabewert dient ein Integer der anzeigt, ob die beiden Objekte gleich sind:

Rückgabewert Bedingung
Kleiner als 0 x ist kleiner als y
0 x und y sind gleich
Größer als 0 x ist größer als y

Um die Liste von Personen nach dem Alter aufsteigend zu sortieren, übergebe ich der Sort() Methode einen Comparison Delegate:

image

persons.Sort( (person1, person2) => person1.Age.CompareTo( person2.Age ) );

Converter<TInput, TOutput> Delegate

Der Converter<TInput, TOutput> Delegate repräsentiert eine Methode die ein Objekt vom Typ TInput als Parameter bekommt und ein Objekt vom Typ TOutput zurückgibt. Der Hauptanwendungsfall ist das Konvertieren von Elementen in einem Array oder einer Liste.

Die Liste von Personen kann z.B. einfach in eine Liste von Namen konvertiert werden:

List<string> names = persons.ConvertAll( p => p.Name );

Durch das Naming der Methode ConvertAll geht auch sehr schön hervor, dass es sich um eine Konvertierung handelt. Dadurch entsteht lesbarer, verständlicher Code.

 

Die generischen Delegates des.Net Frameworks, bieten eine elegante Möglichkeit mit den Containerklassen zu arbeiten. Durch die Verwendung von Lambda Ausdrücken führt das Finden, Sortieren usw. von Listen zur sehr schönem, lesbaren Code. Ich finde die generischen Delegates klasse!

]]>
http://berndhengelein.de/2009/05/funf-freunde-action-predicate-comparison-converter-und-lambda-ausdrucke/feed/ 6