-
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.
|
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 |
Debug Data Binding in WPF
02.04.08 - .NET, WPF Beitrag von Norbert EderEigene 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 |
WPF vs WinForms: Softwareentwickler Performance-Test
31.03.08 - Entwicklung, Diskussionen, .NET, WPF Beitrag von Norbert Eder| | Was macht man Wochenends am Abend, wenn man mit einem anderen Softwareentwickler zusammen sitzt und über einiges aus der eigenen Branche sinniert? Ganz einfach, man kommt auf lustige Ideen und setzt diese dann auch gleich um (oder versucht es zumindest). So vergangenes Wochenende geschehen.
Ausgangspunkt war ein Thread auf dem .NET-Forum.de. Hier kam im Laufe einer Diskussion auf, dass es doch wesentlich schneller und einfacher unter WinForms möglich ist, eine Oberfläche zu erstellen. Schließlich muss man lediglich die einzelnen Elemente in den Designer ziehen, ein wenig konfigurieren und fertig ist die Lösung.
Dem konnte ich so nicht gänzlich zustimmen, zumal man (vorausgesetzt ist weniger ein gekonnter Umgang mit der Maus, vielmehr ist die Fingerfertigkeit bezüglich Tastatur gefragt) in der deklarativen Variante (XAML) sehr gut mittels Copy & Paste (Achtung, Murphy lauert) arbeiten kann und einem so sehr viel Tippslerei erspart bleibt.
Gut, also wurde ein Testszenario ersonnen: Eine kleine Anwendung, die mit Daten aus einem XML gefüttert wird, diese anzeigen soll und zusätzlich die Funktionalitäten Neu, Edit und Save behandeln sollte. Nachdem die Anforderungen definiert wurden musste noch die Stoppuhr gestartet werden und schon konnte es losgehen.
Leider hatten wir keine Videokamera zur Verfügung, sonst hätten wir es in der Tat gefilmt und online gestellt (auch wenn die Lösungen wirklich schmutzig waren), aber der zeitliche Unterschied war schon recht eklatant. Und damit meine ich, dass die WPF-Variante ungefähr 50% der Entwicklungszeit unter WinForms benötigte.
Nun. Natürlich ist dieser Test in keinster Weise wirklich aussagekräftig, noch ist er für den Leser nachvollziehbar (mit Video sähe es anders aus), aber es war grundsätzlich als kleiner Test gedacht um einen ungefähren Anhaltspunkt zu bekommen. Das was sich dabei halt herausgestellt hat war, dass die WPF Lösung auf jeden Fall schneller implementiert war und zusätzlich noch die Möglichkeit der Customization bot, d.h. das Aussehen konnte vollständig angepasst werden. Bei der WinForms-Anwendung: Niete.
Das spricht dann schon wieder eine deutlichere Sprache. Kürzere Implementierungszeit und höhere Anpassbarkeit. Schon eine nette Sache.
Interessant wäre nun der direkte Vergleich in einer größer angelegten Anwendung. D.h. mit einer Implementierungszeit von mehr als 5 MD. Wird sich in der Realität zwar vermutlich nicht spielen, aber durchaus ein interessantes Experiment. Denn gerade auf diesem Gebiet gibt es zahlreiche Spekulationen, wodurch natürlich viele Interessierte verunsichert werden und somit lieber die Finger von dieser Technologie lassen.
| | | 2 Kommentare
- 1252 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
WPF Demo zu Data Binding, DataTemplate usw.
28.03.08 - .NET, WPF Beitrag von Norbert Eder| | Für einen Demo-Anlaß ist gestern eine kleine Beispielanwendung auf Basis WPF entstanden, die ein paar Grundkonzepte vermittelt
- Data Binding
- Data Templates
- CLR Namespaces
- Styles
- usw.
Grundsätzlich tut die Anwendung nicht viel. Sie zeigt lediglich Personendatan innerhalb einer ListBox in Form einer Visitenkarte an. Zusätzlich kann das angehängte Foto (in diesem Fall nur Beispielgrafiken) vergrößert dargestellt werden. Das ganze sieht dann so aus:
Designtechnisch begabte Personen können die Darstellung sicherlich nach belieben verbessern, der WPF-Einsteiger hat die Möglichkeit, sich ein paar Dinge genauer anzusehen. Sicherlich für den Einsteiger ein überschaubares Beispiel.
Da ich es niemanden vorenthalten wollte (würde sonst lediglich auf meiner Festplatte verstauben), hier der Download:
Download WPF Demo
| | | 4 Kommentare
- 2011 mal angesehen
| 1 Trackbacks
| Permalink | Trackback-URL |
WPF: Windows System Fonts in einer CoomboBox darstellen
26.03.08 - .NET, WPF Beitrag von Norbert Eder| | Viele kennen die ComboBox mit den Systemschriften aus den diversen Office-Produkten und auch anderen Anwendungen. Nicht nur, dass der Name der Schrift angezeigt wird, man bekommt auch gleich eine Vorschau.
Dass die Umsetzung nicht aufwändig ist, zeigt nachfolgendes Beispiel. Hierzu das notwendige XAML:
<ComboBox x:Name="FontChooser">
<ComboBox.ItemsPanel>
<ItemsPanelTemplate>
<VirtualizingStackPanel />
</ItemsPanelTemplate>
</ComboBox.ItemsPanel>
<ComboBox.ItemTemplate>
<DataTemplate>
<TextBlock Text="{Binding}" FontFamily="{Binding}"/>
</DataTemplate>
</ComboBox.ItemTemplate>
</ComboBox>
Hier wird eine ComboBox angelegt, das ItemsPanel überschrieben (aus Performancegründen) und ein DataTemplate für die Darstellung der einzelnen Items definiert.
Das DataTemplate besteht aus einem TextBlock, welchem via Data Binding der Text (Name der Schriftart) als auch die FontFamily (die zu verwendende Schriftart zur Darstellung) übergeben werden.
Im Source ist dann nur mehr folgende Zeile notwendig und das Ergebnis kann bewundert werden:
FontChooser.ItemsSource = Fonts.SystemFontFamilies;
Die System-Schriften sind in Fonts.SystemFontFamilies aufgelistet und können direkt an die ItemsSource-Eigenschaft der ComboBox übergeben werden. Damit werden automatisch die einzelnen Items hinzugefügt und die Werte mittels dem oben definierten Data Binding zugewiesen.
Fertig ist die Fonts-ComboBox. Und so sieht sie aus:
| | | 2 Kommentare
- 1921 mal angesehen
| 1 Trackbacks
| Permalink | Trackback-URL |
WPF: Array-Bug oder ist das so gewollt?
25.03.08 - .NET, Grundlagen, WPF Beitrag von Norbert Eder| | Ressourcen sind ja doch eine häufige Angelegenheit in WPF. Klar, immerhin möchten Styles definiert werden, oder manches Mal sollte vielleicht auch ein Array definiert werden, warum auch immer. Und genau hier scheint es ein Problem zu geben.
Ich muss gleich vorweg nehmen, dass ich mich jetzt nicht auf die Suche nach einem offiziellen Bug-Eintrag gemacht habe, sondern poste dies jetzt, da es mir gerade eben aufgefallen ist. Für sachdienliche Hinweise (eine weitere Evaluierung wird meinerseits erst morgen stattfinden) bin ich natürlich dankbar.
Nehmen wir folgendes XAML (eingebettet in ein Window):
<Window.Resources>
<Style TargetType="TextBlock">
<Setter Property="HorizontalAlignment" Value="Center" />
<Setter Property="FontFamily" Value="Comic Sans MS"/>
<Setter Property="FontSize" Value="14"/>
</Style>
<x:Array x:Key="MyPhotos" Type="{x:Type sys:String}">
<sys:String>Blaue Berge.jpg</sys:String>
<sys:String>Sonnenuntergang.jpg</sys:String>
<sys:String>Winter.jpg</sys:String>
</x:Array>
</Window.Resources>
<StackPanel Orientation="Vertical">
<TextBlock Name="textblock1">My Pictures</TextBlock>
<TextBlock>Check out my new pictures!</TextBlock>
<ListBox
x:Name="PhotoBox"
Background="Silver"
SelectedIndex="0"
ItemsSource="{Binding Source={StaticResource MyPhotos}}"/>
</StackPanel>
Eigentlich ist alles korrekt. Das Hauptaugenmerk ist weniger auf den Style, als auf das definierte Array zu legen. Das Problem besteht darin, dass die Daten, welche durch das Array angeboten werden, in der ListBox schlichtweg nicht angezeigt werden.
Nun, das kuriose, wird das Array zu Beginn der Fenster-Ressourcen definiert, dann funktioniert es. Also so:
<Window.Resources>
<x:Array x:Key="MyPhotos" Type="{x:Type sys:String}">
<sys:String>Blaue Berge.jpg</sys:String>
<sys:String>Sonnenuntergang.jpg</sys:String>
<sys:String>Winter.jpg</sys:String>
</x:Array>
<Style TargetType="TextBlock">
<Setter Property="HorizontalAlignment" Value="Center" />
<Setter Property="FontFamily" Value="Comic Sans MS"/>
<Setter Property="FontSize" Value="14"/>
</Style>
</Window.Resources>
<StackPanel Orientation="Vertical">
<TextBlock Name="textblock1">My Pictures</TextBlock>
<TextBlock>Check out my new pictures!</TextBlock>
<ListBox
x:Name="PhotoBox"
Background="Silver"
SelectedIndex="0"
ItemsSource="{Binding Source={StaticResource MyPhotos}}"/>
</StackPanel>
Diese Variante funktioniert tadellos. Der einzige Unterschied: Das Array wurde - wie bereits erwähnt - zu Beginn der Ressourcen definiert.
Selbst wenn dies ein gewolltes Verhalten ist, kann ich es nicht nachvollziehen. Zumal jedes beliebige Array angezeigt werden kann (egal an welcher Position), wenn die erste Definition innerhalb der Ressourcen ein Array ist. D.h. in diesem Fall kann zwischen unterschiedlichen Array-Definitionen auch ein oder mehrere Style-Elemente vorhanden sein, es funktioniert dann trotzdem.
Eigentlich verwirrend, oder nicht?
| | | 2 Kommentare
- 2132 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
WPF: Einführung in die Routed Events
25.03.08 - .NET, Grundlagen, WPF Beitrag von Norbert Eder| | Bisher waren Events genau einem einzigen Element zugewiesen und wurden am angehängten Eventhandler behandelt. Mit WPF wurden die so genannten Routed Events eingeführt, welche sich je nach Strategie durch den WPF Elementbaum bewegen. Insgesamt gibt es drei unterschiedliche Arten dieser Weiterleitungen
- Bubbling
- Tunneling
- Direkt
Bubbling
Zuerst wird der Eventhandler der Quelle aufgerufen. Wird also bein Button geklickt wird der direkt angehängte Eventhandler aufgerufen. Anschließend wird das Event an alle Elternelemente weitergereicht, bis das Wurzelelement erreicht ist.
Tunneling
Der Eventhandler des Wurzelelements wird als erstes aufgerufen. Dieser gibt das Event anschließend an alle Kinder weiter, bis der Auslöser erreicht wird.
Direkt
Die direkte Event-Strategie entspricht der Funktionsweise, wie wir sie bis dato gewohnt waren. D.h. nur das Element selbst erhält das Event.
Warum routed Events
Als Entwickler ist es nicht immer notwendig zu wissen, welche Strategie nun für das Event implementiert wurde, da spezielles Verhalten entsprechend versteckt wurde. Notwendig wird das Wissen um routed Events bei der Erstellung von eigenen Steuerlementen usw.
Listener und Quellen von routed Events müssen kein eigenes Event in ihrer Hierarchie teilen. Jedes UIElement bzw. ContentElement kann ein Listener sein. Vielmehr agieren die routed Events als "Interface" worüber Informationen ausgetauscht werden können.
Ebenfalls ist es möglich, über den Elementbaum hinweg zu kommunizieren, da die Event-Daten an jedes Element im Baum weitergereicht werden und somit für alle sichtbar sind. So kann beispielsweise ein Element die Daten verändern, worauf ein anderes Element entsprechend reagieren kann.
Weitere Informationen
Weitere Informationen können über das MSDN bezogen werden. Ein guter Einstiegspunkt findet sich im Artikel Routed Events Overview.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
WPF: Logischer und visueller Baum
24.03.08 - .NET, Grundlagen, WPF Beitrag von Norbert Eder| | Für einfache Anwendungen unter WPF ist es sicherlich nicht erforderlich, über den logischen und visuellen Baum Bescheid zu wissen. Sobald jedoch eigene Elemente erstellt werden, kommt man unweigerlich damit in Berührung. Daher ist es gut und sinnvoll, den Unterschied zu kennen.
Logischer Baum
Im logischen Baum unter WPF befinden sich alle Elemente, die via XAML bzw. Code erzeugt wurden. Dies ist notwendig, damit nicht nur der Entwickler, sondern WPF selbst über sämtliche Child-Objekte informiert ist und darüber iterieren kann. Ebenfalls wird darüber ein Nachrichtensystem (Notifications) abgebildet. Hilfsmethoden werden über die Klasse LogicalTreeHelper angeboten.
Visueller Baum
Der logische Baum kann nun Elemente enthalten, die nicht unbedingt sichtbar sein müssen. Der visuelle Baum hingegeben (wie der Name schon sagt) beinhaltet alle Elemente, die sichtbar sind und somit von Visual ableiten. Dieser Baum ist vor allem für Entwickler interessant, die ihre eigenen Controls entwickeln und daher genau wissen müssen, wie der visuelle Baum dahinter aussieht. Hilfsmethoden werden über die Klasse VisualTreeHelper angeboten.
Für weitere Informationen empfiehlt sich der Artikel Trees in WPF im MSDN.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Zurück Weiter
|
|
|
|
|
|
|
;)
