Archiv der Kategorie: Software

Ich stelle mir XAML Ressourcen als eine Art statische Felder vor, die beim Starten der Anwendung automatisch initialisiert werden. Natürlich ist dieses Bild etwas vereinfacht, da es Konzepte wie die hierarchische Sichtbarkeit nicht wirklich wiedergeben kann, aber für einen Einstieg in die Thematik sollte es reichen.

Eine der wohl üblichsten Verwendungsarten von in XAML definierten Ressourcen sind sicherlich Abbildungsvorschriften von Daten auf Oberflächenelementen (e.g. <DataTemplate x:Key=“ShortDescription“>) und Styles (e.g. <Style x:Key=“DescriptionHeader“>), ich fand es im Bereich der Oberflächengestaltung auch recht praktisch, beliebige Strukturen vordefinieren zu können (e.g. <StackPanel x:Key=“LongDescription“>).

Genauso nützlich ist es, globale Instanzen einmalig definieren zu können (e.g. <app:ProgramGuide x:Key=“TheGuide“ />), wobei diese sich oft (wenn die Reihenfolge der Definition es erlaubt) auch gegenseitige referenzieren können (e.g. <app:Filter x:Key=“GuideFilter“ /> und <app:ProgramGuideView x:Key=“GuideView“ GuideFilter=“{StaticResource GuideFilter}“ Source=“{Binding Source={StaticResource TheGuide}, Path=Events, IsAsync=true, Mode=OneTime}“ />).

In der Beispielanwendung werden Ressourcen auch für Zeichenketten wie Formate (e.g <system:String x:Key=“DateTimeFormat“>dd.MM.yyyy HH:mm</system:String>) verwendet, wobei allerdings meiner persönlichen Ansicht nach hier die Grauzone zum Aspekt der Lokalisierung auf die gute alte WinForms Art (.resx) berührt wird. Auch wenn WPF anderen Ideen zur allgemeinen Lokalisierung mit sich bringt, könnte es für diese Fälle (Zeichenketten, die lokalisierbar sein sollten, aber nicht direkt in der Oberfläche erscheinen) eleganter sein, auf RESX und die StaticResource Markup Erweiterung zu setzen.

Als letztes finde ich im Rahmen der Beispielanwendung erwähnenswert, dass auch Felder als XAML Ressourcen angelegt werden können (e.g. <x:Array Type=“system:DateTime“ x:Key=“TimeSelections“> und darin <system:DateTime>00:00</system:DateTime> et al).

Happy Coding

Jochen

Eine Frage ist natrürlich, was (welcher Ausschnitt der gesamten Programmzeitschrift) dem Anwender wie (etwa die Sortierung) angezeigt werden soll. Für das Beispiel habe mich mich entschieden, dass die Anzeige sortiert nach dem Startzeitpunkt und gruppiert erst nach Datum und dann nach der vollen Stunde erfolgen soll. Für die Evaluation sind diese Entscheidungen auch festgelegt, produktiv muss man da natürlich freier sein. Tatsächlich ist die vorhandene Implementierung bei Anzeige der gesamten Programmzeitschrift (mit einigen Tausend Einträgen) auch zu langsam, aber das macht für das Beispiel erst einmal nichts – zudem wie gleich beschrieben oft eine Filterung aktiv sein wird.

Ich habe mich entschieden, die Art der Anzeige in einer eigene Klasse zu implementieren. Diese wird dann an die Liste via XAML angehängt (ItemsSource=“{Binding Source={StaticResource GuideView}}“) – die Anzeigeklasse ist wieder einmal eine globale Ressource. Interessant ist im Beispiel das Zusammenspiel mit der Filterbedingung.

Zur Auswahl von Teilen der Programmzeitschrift gibt es eine Filterklasse, in der die üblichen Parameter gesetzt werden können. Ich habe diese auf der untersten WPF Ebene implementiert, die sowohl dynamische Eigenschaften (DependencyProperty mit Bindungen) als auch Ereignisse (RoutedEvent) erlaubt: dem FrameworkElement. Eine Instanz der Klasse wird als globale Ressource angeboten. Dazu noch ein paar weitere Details, der Filter selbst ist trivial und nicht wirklich der Rede wert.

Die eindeutige Filterinstanz wird nun auf zweierlei Art verwendet. Zum Einen binden sich verschiedene Oberflächenelemente direkt an die relvanten Filtereigenschaften – etwa das Eingabefeld mit dem Freitextsuchfeld. Interessant ist dabei, dass bei den Bindungen (Text=“{Binding Source={StaticResource GuideFilter}, Path=TextFilter, Mode=OneWayToSource}“) alternierend OneWayToSource und TwoWay (SelectedItem=“{Binding Source={StaticResource GuideFilter}, Path=Time, Mode=TwoWay}“) verwendet wird: im Allgemeinen wäre OneWayToSource die korrekte Wahl, ich möchte aber einige (wenige) Auswahlelement direkt mit den Voreinstellungen belegen, die nur der Filter selbst kennen muss.

Zur Reaktion auf Änderungen der Filterbedingun bindet sich der CollectionSourceView an die Ereignisse, die bei Veränderungen von der Filterinstanz aufgerufen werden – die Verbindung erfolgt aus Basis der globalen Ressourcen (<app:ProgramGuideView x:Key=“GuideView“ GuideFilter=“{StaticResource GuideFilter}“ Source=“{Binding Source={StaticResource TheGuide}, Path=Events, IsAsync=true, Mode=OneTime}“ />). Die Sicht auf die Programmzeitschrift aktualisiert sich dann selbst, gefolgt von der entsprechenden Aktualisierung in der Benutzeroberfläche. Tatsächlich habe ich es nicht so richtig hinbekommen, der Sicht zu sagen, sie solle sich einfach erneuern. Daher im Code der kleine Trick mit dem NullFilterEvent und dem m_Changing Flag, die dafür sorgen, dass die Filter Eigenschaft des Views verändert wird, ohne dass dabei eine mehrfache Auswertung stattfindt – was stark auf die Laufzeit geht.

Soweit dazu

Jochen