ACHTUNG - NEUES BLOG

Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen EintrÃ¤gen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.

dotnet-gui.com: Neue Community für grafische Oberflächen unter .NET

11.04.08 - Blog-Intern, .NET, WPF, ASP.NET, Silverlight, Allerlei, Internet, Community
Beitrag von Norbert Eder

Seit gestern steht eine neue Community rund um .NET zur Verfügung. Halt nein! Dabei handelt es sich nicht schon wieder um eine gewöhnliche .NET Community. Vielmehr beschäftigt sich dotnet-gui.com mit der Entwicklung von grafischen Oberflächen auf Basis des .NET Frameworks und allen Erweiterungen. Dies inkludiert unter anderem folgende Bereiche:

Windows Forms
Windows Presentation Foundation
Silverlight
Usability
Werkzeuge
und mehr

Erklärtes Ziel ist es, eine Community zu schaffen, die kompetente Hilfestellungen sowohl an Einsteigern und Fortgeschrittenen leisten kann. Weiters sollen konstruktive Diskussionen zu den einzelnen Bereichen unter Gleichgesinnten ermöglicht werden.

Weitere Informationen sind direkt unter dotnet-gui.com verfügbar.

7 Kommentare - 1037 mal angesehen | 1 Trackbacks | Permalink | Trackback-URL

WPF Teil 4: Fehlerbehandlung und Ressourcen

07.04.08 - .NET, Grundlagen, WPF
Beitrag von Norbert Eder

Bisherige Teile:
WPF Teil 1: Die Windows Presentation Foundation aus der Sicht eines Unternehmens
WPF Teil 2: Windows Presentation Foundation oder doch lieber Windows Forms?
WPF Teil 3: Das Softwaredesign will gut überlegt sein

Bereits im dritten Teil wurde besprochen, dass natürlich die Anforderungen ein sehr wichtiges Thema sind und erst darauf aufbauend ein Design entwickelt werden kann. Nun ist ein Softwaredesign jedoch noch nicht alles. Weitere Punkte müssen unbedingt beachtet werden, um nicht später doch noch vor einem Problem zu stehen.

Einführung

Wie in allen Anwendungen (unabhängig, welche Technologien eingesetzt werden) sind Vorarbeiten notwendig, damit das Ergebnis den Wünschen entspricht. Dazu gehören unterschiedliche Dinge, unter anderem:

Fehlerbehandlung
Anpassbarkeit (Customization)
usw.

Gerade diese Punkte können durch ein Softwaredesign nicht 100%ig (bzw. teilweise gar nicht) abgedeckt werden. Jedoch ist es unablässig, diesen Bereichen vor dem Start der Implementierung die notwendige Beachtung zu schenken. Hier soll auf diese Punkte näher eingegangen werden.

Globale Fehlerbehandlung

Fehler treten in jeder Anwendung und in jeder Library auf und müssen entsprechend behandelt werden. Kommt es bei der Framework-Entwicklung vor, dass teilweise Exceptions nicht behandelt werden (da dies vom Verwender vorgenommen werden sollte), ist es bei einer Anwendung, die mit Benutzern zu tun hat, erforderlich, dass alle Fehler abgefangen werden.

Hierzu ist zu entscheiden, welche Fehler der Benutzer tatsächlich zu Gesicht bekommen sollte und welche nicht. Nicht bis zum Benutzer vordringen sollten Exceptions, die vom Benutzer nicht beeinflusst bzw. behoben werden können und von interner Natur sind. Diese sollten in einen Logging-Mechanismus landen, dessen Einträge über ein Incident Management an den Hersteller übertragen werden können.

Treten Fehler (auf Basis von Fehleingaben etc.) auf, die für den Anwender von Relevanz sind, müssen diese den Benutzer entsprechend darauf hinweisen - und das in einer verständlichen und übersichtlichen Form. In diesen Fällen reicht es meist nicht, nur die Message-Eigenschaft einer Exception anzuzeigen.

Da grundsätzlich nicht alle Fehler abgefangen werden (können) bietet sich zudem ein globales Exception-Handling an. Dieses kann in der WPF sehr einfach realisiert werden:

Zu diesem Zwecke ist das Application.DispatcherUnhandledException-Event vorgesehen. Dieses kann entweder via XAML in der App.xaml angegeben werden (der Eventhandler befindet sich in der Codebehind-Datei), oder vollständig in der App.xaml.cs. Der Eventhandler würde wie folgt aussehen:

private void Application_DispatcherUnhandledException(
    object sender, DispatcherUnhandledExceptionEventArgs e)
{
    LoggingManager.GetLog().Error(e.Exception);
    LoggingManager.GetLog().Debug(
        CultureInfo.CurrentCulture, 
        Environment.StackTrace);
}

In diesem Beispiel sorgt ein LoggingManager dafür, dass die Meldungen entsprechend aufgezeichnet werden, um zu einem späteren Zeitpunkt ausgewertet zu werden. Eine Erweiterung wäre hier, die möglichen Exceptions auszuwerten und gegebenenfalls gesondert darauf zu reagieren.

Ressourcen-Behandlung

Wie mit Ressourcen umgegangen wird, hängt sehr stark davon ab, wo und wie die resultierende Anwendung eingesetzt wird. Für eine rein interne Lösung, die für die Konfiguration von internen Systemen verwendet wird, haben Ressourcen meist keine sehr große Bedeutung. Bei Kundenprojekten sieht es schon anders aus.

Ressourcen können unterschiedlichste Dinge beinhalten: Unterschiedliche Sprachen, Grafiken, Konfigurationen, Templates, Styles und anderes ist möglich. Zu entscheiden ist in den einzelnen Fällen, was von externer Stelle manipulierbar sein soll und darf.

Wie bereits angesprochen, ist das Thema Aussehen und Usability bei kleinen internen Anwendungen meist nicht von Bedeutung. Jedoch bedeutet "intern" nicht unbedingt, dass die Anwendung nur von einem kleinen Personenkreis (z.B. nur Entwickler) verwendet wird. Ist dem der Fall gelten die gleichen Regeln wie für externe Anwendungen.

Bei externen Anwendungen gilt zu definieren, ob es sich dabei um Standard-Anwendungen handelt, oder um Grundgerüste, die auf den jeweiligen Kunden hin angepasst werden. Im ersteren Fall wird das Design meist vorgegeben und muss normalerweise nicht geändert werden. Vielmehr möchte man die Anwendung vor Änderungen schützen. Hierzu bietet es sich an, die Ressourcen zu integrieren. Im zweiteren Fall werden nicht nur spezifische Funktionalitäten für den Kunden entwickelt, sondern es müssen auch Anpassungen an die jeweilige Corporate Identity (CI) durchgeführt werden.
Da hierbei eventuell auch Änderungen am Aussehen, an der Platzierung der Elemente etc. direkt vor Ort vorgenommen werden können (ohne einen Entwickler bemühen zu müssen, oder weil der Kunde selbst Anpassungen durchführen möchte) bietet es sich an, die Ressourcen nicht in die Anwendung zu kompilieren, sondern extern zur Verfügung zu stellen.

Dies kann in der WPF bequem mit Hilfe von ResourceDictionaries durchgeführt werden. Damit ist es möglich, Ressourcen aus Dateien einzubinden. Diese Dateien können in einem eigenen Verzeichnis ausgelagert sein und werden von dort eingebunden. Diese ResourceDictionaries können nun beispielsweise Styles und Templates für Elemente beinhalten (sowohl für einzelne Elemente als auch global wirkend). Damit ist das Aussehen einfach steuerbar.

Zu beachten ist weiters, wie die Ressourcen eingebunden werden. Dies kann grundsätzlich auf zwei Arten passieren:

Der Unterschied dieser beiden Markup Extensions liegt darin, wie die Ressourcen geladen werden. Wird eine Ressource statisch gebunden, wird die Ressource beim ersten Zugriff darauf ausgewertet und auf das jeweilige Element angewandt. Bei der dynamischen Ressource kann sich die Ressource zur Laufzeit ändern. Das bedeutet, dass WPF selbst bestimmt, wann die Ressource neu eingelesen und angewandt werden muss.

Mit diesem Wissen gilt es nun zu entscheiden, wann welche Strategie zum Zug kommen soll. Als Faustregel: Was sich zur Laufzeit nie ändert, sollte als statische Ressource eingebunden werden. Was sich ändern kann, dynamisch. Generell sollte man mit dynamischen Ressourcen aber sparsam umgehen, da dies durchaus eine Auswirkung auf die Performance haben kann.

Fazit

Bevor die Implementierung eine Anwendung beginnt, sind zahlreiche Dinge zu klären. Fehlerbehandlung und Umgang mit den Ressourcen ist nur ein kleiner Teil davon. Doch gerade in diesem Bereich finden sich immer wieder Probleme in diversen Anwendungen bzw. Projekten. Klären Sie diese Punkte und etwaige Probleme werden sich zunehmends minimieren.

Kommentar hinzufügen | 1 Trackbacks | Permalink | Trackback-URL

Code Analysis und von WPF generierter Code

07.04.08 - Entwicklung, Diskussionen, .NET, Grundlagen, WPF
Beitrag von Norbert Eder

Die lokale Code Analyse durch Visual Studio 2008 ist eine sehr hilfreiche Sache, um oft gemachte Unschönheiten, eventuelle Performance- und/oder Security-Probleme früh zu erkennen oder auch nur, um die korrekte Namensgebung zu beachten.

Werden die Richtlinien aktiviert (unter den Projekteigenschaften) und zudem einige dieser Richtlinien auf Error gestellt (standardmäßig sind alle als Warnings eingetragen), dann ist man gezwungen, eben diese auch tatsächlich zu beheben. Kein schlechter Weg, um die Qualität des Codes früh auf einen entsprechenden Standard zu heben.

Allerdings gibt es dabei auch einen Haken:
Es gibt die Möglichkeit, generierten Code von der Überprüfung auszunehmen. Dies ist sehr sinnvoll, wenn Code von 3rd-Party-Tools generiert wird und es keine Möglichkeit gibt, die Generierung zu beeinflussen d.h. etwaige Warnings oder Errors los zu werden. Dies kann in den Projekt-Eigenschaften eingestellt werden:

Die WPF selbst generiert ja aus dem definierten XAML im Hintergrund den notwendigen Sourcecode. Wird ein neues Fenster angelegt, besteht dieses aus zwei Dateien:

- Window1.xaml
- Window1.xaml.cs

In der Window1.xaml kann nun per XAML Markup die einzelnen Elemente definiert werden. WIndow1.xaml.cs ist die Codebehind-Datei und enthält den notwendigen Sourcecode (Eventhandler etc.). Nun muss aus der XAML-Datei einiges an Code generiert werden:

Deklaration der einzelnen Elemente, damit via Sourcecode darauf zugegriffen werden kann.
Methode InitializComponent
Methode Connect

All das landet in der Datei Window1.g.cs. Wird also im Hintergrund für uns generiert. (Daher das g in der Endung). Blöderweise erhält diese Datei kein GeneratedCodeAttribute, wodurch die Prüfung auf die Richtlinien hin unterdrückt werden würde.

Im zu Grunde liegenden MSDN-Beitrag findet sich auch kein Hinweis darauf, schließlich wird WPF dort auch noch gar nicht behandelt.

Der einzige Ausweg daraus ist, den erhaltenden Fehler per SuppressMessage auszuklammern und zwar global für den gesamten Namespace. Eine Ausklammerung direkt im Source würde keine dauerhafte Änderung bringen, da das SuppressMessage-Attribute bei der nächsten Generierung überschrieben werden würde.

Hier sollte wohl noch etwas gemacht werden ...

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

Einer dieser Tage ...

07.04.08 - Kunterbunt
Beitrag von Norbert Eder

Diese Woche hat heute in der Früh schon sehr gut begonnen. Da wollte ein Dokument per Email versendet werden. Also, schnell mal eben Zippen (Office-Dokumente, Grafiken, etc.). Just im Moment der Zipperei vertschüsst sich der Rechner. Kein Problem. Neu gestartet, Files vor dem erneuten Zippen nochmals kontrolliert und was ist? Office-Dokument kaputt. Na toll. Und in der letzten Sicherung sind gestern spät abends vorgenommene Änderungen noch nicht drinnen. Juhu.

Merke:
1. Vor dem Zippen, die zu zippende Dateien sichern!
2. Sicherung anwerfen, selbst wenn man vorm PC spät abends schon fast einschläft!

Narf. SSKM.

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

Das .NET BlogBook bricht die 20.000 Downloads-Schallmauer

02.04.08 - Blog-Intern, .NET, Grundlagen, Base Framework, WPF, ASP.NET, Silverlight, Mobile Devices, Datenverwaltung, Visual Studio, Allerlei, Microsoft Office, SQL Server
Beitrag von Norbert Eder

Kürzlich wurde der 20.000ste Download vom .NET BlogBook vollführt. Für mich als Herausgeber ist dies natürlich eine große Freude. Schließlich existiert das .NET BlogBook erst seit knapp mehr als einem Jahr.

Das gibt natürlich Motivation für weitere Anpassungen, Ergänzungen und natürlich Verbesserungen.

Vielen Dank auch an alle Leser, die das Team mit Rückmeldungen motivieren oder Verbesserungen anregen.

Danke!

1 Kommentar - 774 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Externes XML mit der WPF an Elemente binden

02.04.08 - .NET, WPF
Beitrag von Norbert Eder

Data Binding (siehe hier und hier) ist ein sehr wichtiges und häufig genutztes Konzept in der Windows Presentation Foundation.

Kurze Data Binding Einführung

Damit kann eine Datenquelle an ein Element gebunden werden. Je nachdem wie das Binding definiert wird, werden Änderungen in beide Richtungen durchgeschliffen oder nur in eine. Soweit in aller Kürze.

Ein einfaches Beispiel

In vielen Fällen (vor allem kleinere Anwendungen) kommt man mit einer XML-Datei als Quelle aus. In einigen Fällen werden darin nicht nur "unsichtbar" Informationen (Konfiguration etc.) gespeichert, sondern müssen auch einmal angezeigt werden. Idealerweise erledigt man diesen Punkt per Data Binding, da auf damit einiges an Arbeit (und somit auch Zeit) gespart werden kann.

Aber gehen wir ein Beispiel Schritt für Schritt durch.

Wichtig ist, dass ein entsprechendes XML definiert wird. In diesem Fall wird einem neuen WPF Application Projekt ein neues Item XmlData.xml hinzugefügt und ins Unterverzeichnis Resources gelegt. Wichtig ist, in den Eigenschaften der Datei, die Build Action auf Content zu stellen und Copy to Output Directory auf Copy if newer. Damit wird sichergestellt, dass die XML-Datei bei der Ausführung der Anwendung auch tatsächlich vorhanden ist, also in das Output-Verzeichnis kopiert wird.

In diesem einfachen Beispiel enthält die XML-Datei Personendaten und sieht so aus:

<Persons>
  <Person>
    <Firstname>Norbert</Firstname>
    <Lastname>Eder</Lastname>
  </Person>
  <Person>
    <Firstname>Hugo</Firstname>
    <Lastname>Tester</Lastname>
  </Person>
</Persons>

Damit wir auf die XML-Datei als Ressource zugreifen können, müssen wir in unserem Fenster (Window) diese als Ressource definiert werden. Möchte man die XML-Datei anwendungsweit zur Verfügung haben, muss sie als Ressource in der App.xaml definiert werden.

Hierfür ist ein XmlDataProvider zu verwenden. Diesem muss per x:Key ein eindeutiger Schlüssel zugewiesen werden, mit dem auf diese Ressource zugegriffen werden kann. Anschließend ist ein XPath zu definieren, der den Pfad auf die Einträge in der XML-Datei angibt, die angezeigt werden sollen. Schlussendlich ist noch die Eigenschaft Source zu definieren. Diese gibt den Pfad zur XML-Datei an. Und so sieht es aus:

<XmlDataProvider 
    x:Key="PersonsData" 
    XPath="Persons/Person" 
    Source="Resources/XmlData.xml"/>

Damit wäre nun die Ressource definiert und dadurch kann damit gearbeitet werden. Als nächsten Schritt werden alle Einträge an eine ListBox gebunden. Dazu wird im Hauptfenster eine ListBox definiert, deren ItemsSource an die XML-Datenquelle gebunden wird:

<ListBox 
    x:Name="PersonsListBox" 
    Grid.Column="0" 
    Grid.Row="0">
    <ListBox.ItemsSource>
        <Binding Source="{StaticResource PersonsData}"/>
    </ListBox.ItemsSource>
</ListBox>

Dazu wird ein Binding für ItemsSource definiert, welches auf auf statische Art und Weise die Resource mit dem definierten Schlüssel PersonsData zugreift. Diese wird durch den definierten XmlDataProvider repräsentiert.

Wenn nun bei der Auswahl eines Eintrags der ListBox die einzelnen XML-Elemente in eigenen Feldern angezeigt werden sollen, dann kann dies ebenfalls mit einem Binding gelöst werden.

In diesem Beispiel werden die einzelnen Elemente, welche die einzelnen Werte anzeigen sollen, in einem StackPanel angezeigt. Da alle Elemente im StackPanel die gleiche Datenquelle haben, kann die Eigenschaft DataContext des StackPanels genutzt werden.

<StackPanel 
    Orientation="Vertical" 
    DataContext="{Binding ElementName=PersonsListBox, 
                    Path=SelectedItem}" 
    Grid.Column="1" 
    Grid.Row="0">

Was passiert hier? Das StackPanel erhält als Datenkontext den ausgewählten Eintrag der ListBox. Damit nun die Kinder-Elemente des StackPanels die einzelnen Werte anzeigen können, muss bei ihnen ebenfalls ein Binding definiert werden:

<Label Content="{Binding XPath=Firstname}"/>

Im Binding wird ein XPath angegeben und dieser verweist auf das Child-Element Firstname. Dies bedeutet, dass im definierten Label der Vorname des in der ListBox ausgewählten Elements angezeigt werden soll.

Fazit

Diese Beispiel zeigte, wie einfach ein XML Data Binding realisiert werden kann. Notwendig sind dazu natürlich Daten in Form einer XML-Datei und ein wenig Wissen rund um das Thema Data Binding. Mit Hilfe dieses Beispiels sollten erste Binding-Versuche erfolgreich abgeschlossen werden können.

Download WPF Xml Data Binding Demo

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

Microsoft Live Search vs Google - Microsoft's Nachteil

02.04.08 - Kunterbunt
Beitrag von Norbert Eder

Die Suche von Google ist ja eigentlich als die einzige wirkliche Innovation von Google zu werten. Die Live Search von Microsoft gilt ja weitläufig nicht unbedingt als Innovation. Dennoch habe ich mir angewöhnt, die Live Search zu benutzen (anstatt Google), da die Ergebnisse mittlerweile gut sind.

Das was mir aber immer wieder dabei auffällt:
Ich habe zwar die Live Search als Startseite eingerichtet, aber im Sinne der Wiederverwendbarkeit, benutze ich immer wieder ein bereits geöffnetes Tab. Anstatt jedoch auf den Home-Button zu klicken, klicke ich meist in die Adressleiste und tippe die URL schnell ein. Und dabei ist mir ein gewaltiger Nachteil der Live-Search aufgefallen. Für viele nicht neu, für mich eigentlich auch nicht (hab es mir immerhin schon öfter gedacht), aber eben erst jetzt mal ein Post dazu, weil dies sicher besser gemacht werden könnte:

Die Eingabe von www.google.at geht einfach wesentlich schneller von der Hand als search.live.com (absichtlich nicht verlinkt). Echt. Das ist ein Nachteil, liebe Jungs aus Redmond.

6 Kommentare - 761 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Debug Data Binding in WPF

02.04.08 - .NET, WPF
Beitrag von Norbert Eder

	Fehler im Data Binding können durchaus eine nervige Angelegenheit sein, zumal sie manchmal nicht wirklich einfach zu finden sind. Einen sehr ausführlichen und vor allem interessanten Beitrag zu diesem Thema hat Beatriz Costa verfasst: How can I debug WPF bindings? Sehr empehlenswert!
	Kommentar hinzufügen \| 1 Trackbacks \| Permalink \| Trackback-URL

Eigene WPF Sektion verfügbar

02.04.08 - Blog-Intern, .NET, WPF
Beitrag von Norbert Eder

Um dem 1. April und den üblichen Scherzen aus dem Weg zu gehen, möchte ich erst Heute auf die neue verfügbare Sektion aufmerksam machen. Ab sofort steht ein Bereich speziell für die WPF zur Verfügung. Darin finden sich zur Zeit ausgewählte Blog-Artikel. Weitere Informationen, How-To's, Ressourcen, Links etc. werden im Laufe der Zeit hinzukommen, um zukünftig einen möglichst guten Anlaufspunkt zu diesem interessanten Thema zu bieten.

Zum WPF Bereich

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

Die Trickkiste geht in die nächste Runde

31.03.08 - Blog-Intern
Beitrag von Norbert Eder

	Wieder einmal ist es soweit. So sind doch wieder einige Artikel hinzugekommen, die anscheinend von größerem Interesse sind/waren. Diese wurden daher in die Trickkiste aufgenommen und können darüber nun einfach gefunden werden. Wo wurden Erweiterungen durchgeführt: - WPF - Design Patterns Für Anregungen etc. bin ich natürlich immer zu haben, also einfach nur aufschreien :)
	Kommentar hinzufügen \| 0 Trackbacks \| Permalink \| Trackback-URL

Zurück Weiter