-
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.
|
WPF und die Lesbarkeit von kleinen Schriftgrößen
19.08.08 - .NET, WPF Beitrag von Norbert Eder| | In einigen Fällen kann es durchaus vorkommen, dass Texte, welcher in einer kleinen Schriftgröße gehalten sind, nur schwer zu lesen sind.
Damit diese Fälle umgangen werden können ist es wichtig zu wissen, wie das Rendering von Texten funktioniert.
Einen Beitrag zu diesem Thema ist durch den Artikel Text Clarity in WPF gegeben. Darin wird im Detail erklärt, wann der Text wie gerendert wird, wann es zu Problemen kommen kann und wie diese zu umgehen sind.
Sehr empfehlenswert.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
dotnet-gui.com: Es gibt Neuigkeiten
18.08.08 - .NET, WPF, Internet, Community Beitrag von Norbert Eder| | Auf www.dotnet-gui.com tut sich etwas. Neben den mittlerweile recht bekannten Artikeln gibt es jetzt einen zusätzlichen Bereich.
Gerade kleine Beiträge, kurze Hilfen erfreuen sich großer Beliebtheit. Daher gibt es nun einen eigenen Bereich How To. Darin werden zukünftig verstärkt kleine Codeblöcke, kurze Beschreibungen etc. bereitgestellt, die keine Artikel darstellen, aber schnelle und einfache Lösungen anbieten.
Jeder WPF-Begeisterte ist natürlich herzlichst eingeladen, seinen Beitrag zu tätigen. Zu berücksichtigen ist lediglich, dass dieser Bereich moderiert wird. Dadurch soll ein Mindestmaß an Qualität gewährleistet werden.
PS: Wer auf dotnet-gui.com ein Blog betreiben möchte, der kann dies gerne tun. Du musst dazu kein WPF-Experte sein. Deine Themen sollten sich um grafische Oberflächen rund um .NET drehen, dabei kannst du sowohl aus Entwickler-, Designer-, oder auch Anwendersicht berichten.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
WPF, NHibernate, ObservableCollection und Patterns
10.08.08 - Entwicklung, Diskussionen, Patterns, .NET, WPF Beitrag von Norbert Eder| | Im Beitrag ObservableCollection und NHibernate hatte ich einen Link zu einem Artikel gepostet, der zeigt, wie man NHibernate dazu bringt, mit einer ObservableCollection zu arbeiten.
Nun, ein paar Tage später, finde ich die Sache dann doch nicht mehr ganz so toll, gerade wenn Patterns mit ins Spiel kommen (was hoffentlich der Fall ist). Man nehme als Beispiel die bereits von mir vorgestellten Patterns MVC für WPF und Model-View-ViewModel. Diese beiden Patterns unterscheiden sich unter anderem dadurch, dass beim MVC Controller und Model komplett getrennt sind. Beim MVVM ist dies zwar auch der Fall, jedoch stellt das ViewModel sowohl die Controller-Funktionalität zur Verfügung, als auch eine gewrappte Form des Models.
Was bedeutet dies nun konkret?
Bei der Verwendung des MVVM Patterns zusammen mit NHibernate bedarf es keiner speziellen Erweiterung oder Anpassung. Das Model verwendet weder eine ObservableCollection noch wird irgendein für WPF benötigtes Interface implementiert (siehe beispielsweise INotifyPropertyChanged). Damit ist es möglich, NHibernate zu nutzen, wie es auch ausgeliefert wird. Beim MVC-Pattern müsste hier der im verlinkten Artikel angesprochene Handkniff getätigt werden, um in den Genuss der für das Data Binding notwendigen Events zu gelangen.
Was kann daraus abgeleitet werden?
Der – zumindest für mich – wesentliche Punkt ist, dass es sinnvoll wäre, das zu verwenden, was sich bereits vielfach bewährt hat. NHibernate hat sich bereits in sehr vielen Projekten bewährt und man kann sich auf eine korrekte Funktionsweise verlassen. Aus diesem Grund würde ich eher die Finger von einer ObservableCollection-spezifischen Erweiterung lassen (auch wenn es lediglich eine Handvoll Klassen sind) und hier auf das MVVM-Pattern zu setzen, welches eben diese Änderung nicht benötigt.
Damit muss man sich bei einem Update keine Sorgen machen und wer weiß, vielleicht gibt es ja bald eine entsprechende Unterstützung.
Was meint ihr dazu?
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
ObservableCollection und NHibernate
06.08.08 - .NET, WPF Beitrag von Norbert Eder| | Wer Anwendungen entwickelt (unabhängig ob WPF oder nicht) kommt irgendwann in die Verlegenheit, einen O/R-Mapper einzusetzen. Im Falle von WPF kann sich daraus (je nach eingesetzem Pattern) die Problematik ergeben, dass NHibernate von Haus aus keine ObservableCollection unterstützt, welche jedoch für ein Data Binding notwendig ist (je nach Anwendungsfall).
Zufällig bin ich auf einen Artikel gestoßen, welcher dieses Problem behandelt und eine entsprechende Lösung für dieses Problem bietet und zusätzlich eine Demo-Anwendung zur Verfügung stellt:
Bridge the Gap Between Your NHibernate Collections and WPF UI
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
MVVM Pattern mit WPF verwenden
06.08.08 - .NET, WPF Beitrag von Norbert Eder
Debugging Windows Presentation Foundation
28.07.08 - WPF Beitrag von Norbert Eder| | Im Artikel WPF: Unterstützung beim Debuggen von WPF-Anwendungen hatte ich bereits über Möglichkeiten des Debuggings bei WPF-Anwendungen gesprochen. Inzwischen hat sich jedoch so einiges getan. Ich musste mit Schrecken feststellen, dass ich darüber noch gar nicht berichtet hatte. Das möchte ich damit nachholen.
Josh Smith hat ja seinerzeit mit Woodstock for WPF ein Debugging-Tool für WPF vorgestellt. Die Idee war grundsätzlich eine sehr gute, worauf sich gleich ein Dreiergespann (Josh Smith, Karl Shifflett und Andrew Smith) zusammen tat, um dieses Tool wesentlich zu verbessern.
Als Resultat entstand Mole for WPF, nachfolgend auch abgebildet.
Dabei handelt es sich um einen Debugging-Visualizer, welcher eben im Debugging-Mode angeworfen werden kann. Darin sind nun sämtliche Werte, Eigenschaften, Visual Tree, Logical Tree aufgelistet und können auch verändert werden. Ein Debugging fällt daher schon recht einfach.
Wer sich also mit der Windows Presentation Foundation beschäftigt, wird um dieses Tool kaum umhin kommen, da es dann doch die eine oder andere Stunde des frustrierten Fehlersuchens ersparen kann.
Eine ausführliche Dokumentation, Link zu Videos und natürlich der Download selbst, ist auf CodeProject.com zu finden.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
WPF: Unterschied zwischen DataTemplate und ControlTemplate
14.07.08 - .NET, WPF Beitrag von Norbert Eder| | Sehr oft wird in Foren bzw. per Email gefragt, wo denn genau der Unterschied zwischen einem DataTemplate und einem ControlTemplate liegt. Dies ist relativ einfach erklärt.
DataTemplate
Ein DataTemplate wird verwendet, um das Aussehen bzw. die Zusammensetzung eines Daten-Items zu beschreiben. D.h. darüber wird der Visual Tree eines Daten-Items definiert. Relevant ist dies bei Items für eine ListBox, ListView usw. Dabei kann es sich um eine Ableitung eines ListBoxItems (je nach Steuerelement) oder um eine CLR-Objekt handeln.
ControlTemplate
Ein ControlTemplate hingegen beschreibt den Visual Tree und damit den Aufbau eines Steuerelements.
Fazit
Sollen also Items einer "Auflistung" beschrieben werden, dann ist die Verwendung eines DataTemplates zielführend. Andernfalls ist ein ControlTemplate zu verwenden.
| | | 1 Kommentar
- 12491 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
WPF: DataSet und Data Binding
09.07.08 - .NET, WPF Beitrag von Norbert Eder| | Gerade zum Thema Data Binding habe ich mittlerweile einige Beispiele erstellt (siehe hier, hier und hier). Was noch fehlt (und oft gefragt wird) ist, wie ein DataSet gebunden werden kann. Dem möchte sich dieser Artikel widmen.
Auch in diesem Fall ändert sich relativ wenig. Anstatt eines konkreten Objektes steht nun ein DataSet zur Verfügung. Dieses kann Tabellen enthalten (0 - n) und jede Tabelle kann Spalten enthalten. Das Grundprinzip besteht nun einfach darin:
Vorgehensweise anhand einer TreeView
Das DataSet wird als DataContext bei der TreeView gesetzt. Das Root-Element wird beispielsweise per Hand (Markup) angelegt. Diesem wird nun eine Tabelle des DataSets als ItemsSource gesetzt. In weiterer Folge wird ein HierarchicalDataTemplate erstellt, welches nun dafür zuständig ist, die einzelnen Felder (oder auch nur ein paar wenige davon) darzustellen.
In weiterer Folge kann nun eine Eingabemaske erstellt werden, welche an das SelectedItem der TreeView gebunden ist und den ausgewählten Datensatz zur Anzeige bringt und somit bearbeitbar macht.
Konkretes Beispiel
Ob nun das DataSet aus einer Datenbank geladen oder manuell erstellt wird, macht keinen Unterschied. In diesem Beispiel wird ein DataSet per Code generiert und zur Verfügung gestellt:
public static class DataSetMock
{
public static DataSet CreateDataSet()
{
DataSet ds = new DataSet();
ds.Tables.Add("Person");
ds.Tables[0].Columns.Add("FirstName");
ds.Tables[0].Columns.Add("LastName");
ds.Tables[0].Rows.Add("Norbert", "Eder");
ds.Tables[0].Rows.Add("Hugo", "Tester");
return ds;
}
}
Dies geschieht in diesem Fall durch eine statische Klasse. Die Methode CreateDataSet kann nun über einen ObjectDataProvider via XAML zur Verfügung gestellt werden. Damit beschränken wir uns beim Schreiben von Sourcecode auf die Implementierung eben dieser statischen Klasse.
Wie bereits angesprochen, wird das DataSet in diesem Beispiel über ObjectDataProvider zur Verfügung gestellt:
<ObjectDataProvider
x:Key="PeopleProvider"
MethodName="CreateDataSet"
ObjectType="{x:Type local:DataSetMock}"/>
Der Provider selbst muss in den entsprechenden Ressourcen (in diesem Fall in den Ressourcen des Fensters) definiert werden.
In weiterer Folge wird nun ein TreeView-Element auf dem Fenster positioniert. Als DataContext wird der zuvor erstellte Provider gesetzt, da dieser die generierten Daten (DataSet) zurück liefert:
<TreeView
DataContext="{StaticResource PeopleProvider}"
x:Name="PeopleTreeView"
DockPanel.Dock="Left"
Width="200">
<TreeViewItem
x:Name="PeopleRoot"
Header="People"
ItemsSource="{Binding Person}"
ItemTemplate="{StaticResource PersonTemplate}"/>
</TreeView>
Im Source ist zusätzlich zu sehen, dass eine Root-Node über das Markup erstellt wird. Diesem Root-Node wird als ItemsSource nun per Binding die Tabelle Person aus dem DataSet zugewiesen. Dadurch wird der Gültigkeitsbereich des Bindings für diese Node festgelegt. Somit kann nun ein ItemTemplate definiert werden, welches für die Darstellung der einzelnen Datensätze zuständig ist:
<HierarchicalDataTemplate x:Key="PersonTemplate">
<StackPanel Orientation="Horizontal">
<TextBlock Text="{Binding LastName}"/>
<TextBlock Text=", "/>
<TextBlock Text="{Binding FirstName}"/>
</StackPanel>
</HierarchicalDataTemplate>
Dieses Template wird ebenfalls in den Ressourcen des Fensters abgelegt. Zusätzlich muss es der Root-Node als ItemTemplate zugewiesen werden.
Das wären bezüglich TreeView alle notwendigen Schritte. Möchte man nun ein Eingabeformular erstellen, welches die Daten des aktuell selektierten Datensatzes anzeigen soll, dann kann nun folgendes definiert werden:
<StackPanel Orientation="Vertical">
<TextBlock Text="Firstname"/>
<TextBox
Text="{Binding
ElementName=PeopleTreeView,
Path=SelectedItem.FirstName}"/>
<TextBlock Text="Lastname"/>
<TextBox
Text="{Binding
ElementName=PeopleTreeView,
Path=SelectedItem.LastName}"/>
</StackPanel>
Was passiert hier? Es wird ein StackPanel definiert, welches alle Kind-Elemente untereinander anordnet. Die Elemente vom Typ TextBlock stellen die Überschriften dar. Für die eigentlichen Daten wird jeweils eine TextBox verwendet. Diese enthalten ein Binding auf die jeweilige Spalte des aktuell selektierten Datensatzes. Änderungen schlagen sich natürlich sofort auf die TreeView durch.
Fazit
Das Data Binding funktioniert grundsätzlich immer gleich. Wichtig ist, dass bewußt ist, wann welcher Kontext gesetzt wird und was dieser Kontext tatsächlich zur Verfügung stellt. Darauf kann gebunden werden. Dies verhält sich bei einem DataSet gleich wie bei einer Objekthierarchie.
Das gezeigte Beispiel steht natürlich als Download zur Verfügung.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Sie wurden mit dem Microsoft MVP Award ausgezeichnet!
01.07.08 - Blog-Intern, .NET, WPF, Internet, Community Beitrag von Norbert Eder| | Sehr geehrte(r) Norbert Eder,
Herzlichen Glückwunsch! Wir freuen uns, Ihnen den Microsoft® MVP Award 2008 verleihen zu können. Mit dem MVP Award danken wir Ihnen für Ihren Einsatz für die Community, mit dem Sie Tag für Tag dazu beitragen, das Leben der Menschen zu bereichern und die Branche erfolgreicher zu machen. Wir schätzen Ihren außerordentlich bedeutenden Beitrag in den technischen Communities zum Thema Microsoft Client App Dev im vergangenen Jahr hoch ein.
Tja, was soll ich sagen. Ich fühle mich geehrt und bedanke mich natürlich bei allen, die mich immer wieder unterstützen, die die Nominierung möglich gemacht haben und sowieso und überhaupt bin ich auch für Weltfrieden.
Mal sehen, ob die sich aufdrängende Frage auch noch irgendwie beantwortet wird ...
| | | 23 Kommentare
- 1506 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Artikel: Steuerelemente für jeden Zweck
30.06.08 - .NET, WPF Beitrag von Norbert Eder| | In der aktuellen Ausgabe der visual studio one wurde mein Artikel Steuerelemente für jeden Zweck veröffentlicht.
Die Idee der Steuerelemente ist ja nicht neu. Relativ neu hingegen ist die Möglichkeit, grafische Elemente komplett von der eigentlichen Logik zu trennen – zumindest gilt dies für Microsoft-basierte Technologien.Mit der Windows Presentation Foundation wird den Entwicklern genau dies in die Hand gelegt. Sie als Entwickler und auch Ihr Kunde können davon profitieren. Dieser Artikel zeigt Ihnen, wie Sie dynamische WPF-Steuerelemente selber bauen können.
Link: visual studio one
| | | 3 Kommentare
- 903 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL | Zurück Weiter
|
|
|
|
|
|
|